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ABSTRACT 


Advances  in  simulation  methodology,  and  the  computer 
support  systems  to  implement  these  methodologies,  have  led  to 
the  development  of  integrated  simulation  support  environ¬ 
ments.  These  environments,  or  collection  of  software  tools, 
seek  to  aid  the  analyst  in  developing  models,  data  management 
and  analysis,  and  data  presentation. 

While  an  integrated  simulation  environment  provides  a 
more  organized  structure  for  managing  and  performing  simula¬ 
tion  projects,  and  provides  a  database  management  structure 
for  storing,  manipulating,  and  analyzing  data,  they  do  not 
address  the  actual  process  of  going  out  and  obtaining  the 
data.  As  a  result,  many  of  the  common  problems  associated 
with  poor  problem  and  system  definition,  and  low  quality 
model  input  data,  may  still  occur. 

To  solve  this  problem,  this  study  examines  the  concept 
of  developing  a  "support-support"  system;  a  portable  micro¬ 
computer  with  software  tools  designed  to  support  collection 
of  the  data,  both  subjective  and  objective,  required  in  a 
simulation  study.  This  data  can  then  be  ported  into  the 
integrated  support  system  for  analysis  and  model  development. 

In  developing  this  concept,  the  simulation  process  is 
better  defined  using  structured  analysis  diagrams.  Based  on 
this  analysis  the  runctions  that  a  support-support  system 
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could  best  accomplish  are  identified  and  a  conceptual  speci 
fication  developed.  An  implementation  strategy  is  proposed 
which  is  based  on  the  use  of  readily  available  software 
tools,  such  as  dBASE  III,  and  the  use  of  a  simple  program¬ 
ming  language,  such  as  BASIC. 

To  demonstrate  how  this  strategy  can  be  implemented,  a 
BASICA  program  was  developed  to  support  model  input  data 
collection.  Using  a  graphic  display  to  define  input  data 
requirements  and  single  key  inputs,  this  program  should 
maximize  the  time  an  analyst  can  spend  observing  the  system 
and  minimize  the  time  he/she  has  to  spend  entering  data. 
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ABSTRACT 


Advances  in  simulation  methodology,  and  the  computer 
support  systems  to  implement  these  methodologies,  have  led  to 
the  development  of  integrated  simulation  support  environ¬ 
ments.  These  environments,  or  collection  of  software  tools, 
seek  to  aid  the  analyst  in  developing  models,  data  management 
and  analysis,  and  data  presentation. 

While  an  integrated  simulation  environment  provides  a 
more  organized  structure  for  managing  and  performing  simula¬ 
tion  projects,  and  provides  a  database  management  structure 
for  storing,  manipulating,  and  analyzing  data,  they  do  not 
address  the  actual  process  of  going  out  and  obtaining  the 
data.  As  a  result,  many  of  the  common  problems  associated 
with  poor  problem  and  system  definition,  and  low  quality 
model  input  data,  may  still  occur. 

To  solve  this  problem,  this  study  examines  the  concept 
of  developing  a  "support-support"  system;  a  portable  micro¬ 
computer  with  software  tools  designed  to  support  collection 
of  the  data,  both  subjective  and  objective,  required  in  a 
simulation  study.  This  data  can  then  be  ported  into  the 
integrated  support  system  for  analysis  and  model  development. 

In  developing  this  concept,  the  simulation  process  is 
better  defined  using  structured  analysis  diagrams.  Based  on 
this  analysis  the  functions  that  a  support-support  system 
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CHAPTER  1 
INTRODUCTION 

Background 

In  recent  years  there  have  been  numerous  advances  in 
the  "art  and  science"  of  simulation  and  associated  soft¬ 
ware.  New  simulation  languages  and  methodologies  have  been 
developed  that  reflect  a  "shift  from  the  program  to  the  model 
view  of  the  simulation  process"  (Nance  1983).  There  has 
also  been  an  increased  interest  in  the  development  of  support 
software  and  simulation  "environments"  that  comprise 
integrated  collections  of  these  software  tools  (Henricksen 
1984).  One  of  the  more  visible  areas  has  been  in  the  area  of 
interactive  simulation  involving  graphics  and  animation. 

In  regards  to  simulation  environments,  an  integrated 
environment  is  a  collection  of  software  tools  for  designing, 
writing,  and  validating  models;  writing  and  verifying  data; 
and  designing  and  carrying  out  experiments  with  models.  An 
important  asp e c t  of  an  integrated  environment  is  that  the 
user  is  shielded  from  being  a  computer  technician,  i.e., 
having  to  spend  a  significant  amount  of  time  managing  files, 
making  sure  data  are  in  correct  formats,  etc.  (Henricksen 
1984;  Standridge  and  Walker  1983). 

Additionally  termed  as  integrated  simulation  support 
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systems,  they  seek  to  "deal  with  other  aspects  of 


performing  a  simulation  project  such  as  model  building, 
user  data  management,  data  analysis,  and  data  presentation 
(Standridge  and  Walker,  1983).  A  primary  attribute  is 
integrated  data  management,  which  seeks  to  address  the  needs 
of  newer  simulation  methodologies  and  the  complexity  of  the 
systems  now  being  modeled  (Standridge  1983;  Evers  Bachert, 
and  Santucci  1981).  Standridge  (1985)  states  that  the 
requirements  for  these  systems  have  evolved  to  include:  1)  a 
framework  which  provides  a  more  standardized  way  for 
performing  a  simulation  project;  2)  a  system  which  provides 
effective  user  interfaces;  and  3)  a  system  which  is 
integrated . 

Such  a  system,  coupled  with  a  effective  methodology,  can 
alleviate  many  of  the  problems  and  failures  of  simulation 
projects.  These  problems  include  the  need  to  effectively 
communicate  model  formulation  and  assumptions;  poor 
communication,  both  with  user  and  project  team  members; 
"failure  to  use  modern  tools  and  techniques  to  manage  the 
development  of  a  large,  complex  computer  program";  and 
failure  to  adequately  describe  the  system  (Evers,  Bachert, 
and  Santucci  1981;  Annino  and  Russell  1979;  Hahn  and  Comer 
1981) . 

Other  just  as  common  problems  result  from  poor  or 
inadequate  data,  where  data  is  defined  in  its  broadest  con¬ 
text  to  include  subjective  data,  such  as  information  about 
the  problem,  objectives,  and  system  to  be  modeled;  as  well 
as  objective  data  such  as  that  used  to  define  variable/para- 
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meter  inputs  and  to  validate  the  model.  Some  of  these  prob¬ 
lems  include: 

1)  A  poor  and  incomplete  definition  of  the  problem. 

2)  Failure  to  identify  the  objectives  of  the  model. 

3)  Failure  to  adequately  identify  the  data  needed  to 
execute  the  model  and  how  this  data  is  to  be 
collected. 

4)  Using  statistical  procedures  that  the  data  is  indep 
endent  and  identically  distributed  when  is  is  not. 

5)  Assuming  observations  in  the  data  set 
are  homogeneous  when  they  are  not. 

(Miller  and  Pare  1986;  Evers,  et  a 1 .  1981;  Shannon  1975). 


Problem/Scope 


While  an  integrated  simulation  environment  provides  a 
more  organized  structure  for  managing  and  performing  simula¬ 
tion  projects,  and  provides  a  database  management  structure 
for  storing,  manipulating,  and  analyzing  data,  they  do  not 
address  the  actual  process  of  going  out  and  obtaining  the 
data.  Thus  many  of  the  above  mentioned  problems  may  still 
occur  . 


This  research  effort  has  focused  on  better  defining  the 
simulation  process,  particularly  the  "upfront"  process,  with 
an  eye  towards  developing  a  system  specification  for  what 
could  be  termed  a  support-support  system.  The  objective  or 
purpose  of  such  a  system  would  be  to  provide  a  more  organize 
or  disciplined  approach  and  tool  for  the  data  collection 
phases  of  a  simulation  project.  This  would  in  turn  reduce 
the  chances  of  failure  due  to  poor  or  inadequate  data. 


Assumptions 


The  development  of  this  topic  and  problem  statement 
were  motivated  by  and  based  on  the  following  assumptions. 

They  also  have  influenced  the  approach  taken  in  trying  to 
resolve  this  problem.  While  it  is  felt  that  these  assump¬ 
tions  (except  no.  10)  are  supported  by  other  sources,  they 
will  be  stated  without  justification  at  this  point  and 
addressed  separately  throughout  this  report.  Some  have 
already  been  stated  or  implied,  but  will  be  restated  here 
for  clarity . 

1.  Data  collection  also  involves  the  collection  of 
subjective  data  such  as,  understanding  the  user's 
problem,  identifying  system  components  and  how 

they  interact,  identifying  key  decision  makers,  etc. 

2.  Data  collection  is  a  very  important  and  often  times 
underestimated  part  of  the  simulation  process.  It 
is  also  sometimes  overlooked  or  assumed  away. 

3.  An  integrated  simulation  support  system,  such  as  the 
Extended  Simulation  System  (TESS)  is  a  valuable  aid 
in  properly  executing  a  simulation  project. 

4.  The  new  simulation  analyst  is  very  poorly  prepared 
to  properly  undertake  a  simulation  project.  Most 
simulation  texts,  while  acknowledging  the  importance 
of  the  initial  phases  of  the  simulation  process 

do  not  expand  on  how  to  do  it  but  rather  focus  on 
simulation  as  a  software  development  process  (prog¬ 
ramming  exercise). 

5.  There  is  not  an  integrated  support  system  that 
currently  supports  this  collection  of  subjective 
data,  nor  objective  data;  unless  one  considers  the 
more  sophisticated  data  acquisition  systems  that 
automatically  collect  and  archive  system  data. 

6.  Despite  the  existence,  and  ideally  the  benefits,  of 
using  a  computer  controlled  data  acquisition  system, 
there  are  still  circumstances  that  require 
collection  by  observation.  This  is  particularly 
true  when  dealing  with  subjective  data  which 
involves  observing,  interviewing,  and  researching. 
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7.  The  microcomputer  can  be  a  powerful  tool  in  carry¬ 
ing  out  simulation  studies. 

8.  The  potential  of  the  "laptop"  portable  microcomputer 
has  not  been  fully  exploited.  Furthermore,  the 
portable  microcomputer  could  form  the  basis  for  an 
integrated  support-support  system. 

9.  Experience  and  an  effective  methodology  (procedures) 
are  key  elements  in  overcoming  many  of  the  failures 
of  simulation  projects.  However,  a  system  which 
incorporates  the  experience  of  experts  and  is  based 
on  proper  procedure  could  overcome,  in  part,  a  lack 
of  experience . 

.0.  For  computer  software  to  be  accepted  and  used  by  a 

prospective  user  it  must  not  only  be  adaptable  to  to 
the  task  to  be  accomplished,  but  also  to  the 
particular  individual  user. 


Approach 


In  approaching  this  problem  it  was  felt  the  future  is 
represented  by  integrated  support  systems  and  while  data 
acquisition  systems  feeding  the  central  data  base  of  such  a 
system  is  the  ideal,  this  is  not  always  possible.  The  next 
step  dov/n  from  this  would  be  a  portable  computerized  system 
which  was  designed  along  the  same  lines  as  the  support  system 
and  could  be  used  by  the  analyst  to  guide  his  data  and  infor¬ 
mation  collection  efforts.  The  results  could  then  be  ported 
to  the  main  support  system  for  final  analysis  and  use  in 
modeling  the  system  and  running  the  simulation.  It  is  felt 
such  a  system  can  provide  an  organized  and  structured  frame¬ 
work  for  the  early  phases  of  the  project  which  in  some  cases 
would  simplify  the  process  and  make  it  more  efficient,  and  in 
all  cases  aid  in  avoiding  some  of  the  more  common  mistakes. 
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The  study  thus  began  with  a  look  at  the  simulation  ’ 
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process  with  emphasis  on  the  early  phases.  The  process  was  ■ 

then  further  broken  down  so  as  to  identify  all  the  tasks  that 
would  have  to  be  performed  during  the  investigation  and  col¬ 
lection  phase.  Those  tasks  that  could  then  be  computerized 
were  identified. 

Next,  the  status  and  concepts  of  simulation  support 
environments  were  investigated.  Combining  these  concepts 
with  the  tasks  to  be  performed,  a  system  specification  was 
developed  which  defined  the  requirements  of  a  support-support 
system.  This  specification  was  also  based  on  the  current  use 
of  portable  computers/data  collectors,  particularly  in  the 
area  of  work  measurement. 

Finally,  because  time  prevented  the  building  of  an 
entire  system,  a  generic  data  collection  program  was  develop¬ 
ed  which  was  based  on  the  concepts  detailed  in  the  system 
specification.  Because  the  bulk  of  the  information  currently 
available  deals  with  the  collection  of  objective  data 
(numbers)  this  software  supports  the  collection  of  such  data. 

This  is  not  to  imply  that  such  a  system  cannot  or  should  not 
support  the  collection  of  subjective  data.  It  should  and  it 
must  in  order  to  be  a  complete  and  useful  system. 


j  Report  Overview 

i 

This  report  will  generally  follow  the  approach  outlined 
above.  Chapters  2  discusses  the  problem  in  more  depth. 
Chapter  3  looks  at  the  simulation  process  and  describes  the 
procedure  used  to  better  define  this  process.  Chapter  4  then 


presents  a  generic  system  specification  for  a  support-support 
system  and  Chapter  5  discusses  how  this  specification  could 
conceptually  be  implemented.  Chapter  6  then  takes  a  detailed 
look  at  an  input  collection  program  which  partially  imple¬ 
ments  the  system  specification.  Because  much  remains  to  be 
done  before  a  complete  system  exists,  Chapter  7  discusses 
areas  for  future  research. 
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CHAPTER  2 


PROBLEM  DISCUSSION 


Introduction 


This  chapter  will  expand  on  the  background  material  and 
problem  statement  provided  in  Chapter  1.  It  represents  a 
brief  review  of  the  literature  and  also  a  more  complete  just¬ 
ification  of  the  problem.  The  next  section  will  begin  with 
a  personalized  view  of  the  problem  and  then  expand  this 
discussion  to  involve  other  problems  that  confront  the  simul¬ 
ation  analyst.  Then  some  of  the  methodologies  that  have  been 
proposed  to  solve  these  problems,  and  the  more  sophisticated 
support  systems  that  support  these  methodologies  will  be 
discussed.  Finally,  the  last  section  will  come  full  circle 
in  that  despite  tremendous  advances  in  both  methodologies 
and  support  systems,  the  problem  outlined  in  first  section 
still  essentially  exists. 


The  Problem  --  A  Personal  View 


Simulation  is  "the  process  of  designing  a  model  of  a 
real  system  and  conducting  experiments  with  this  model  for 
the  purpose  either  of  understanding  the  behavior  of  the  sys¬ 
tem  or  of  evaluating  various  strategies  (within  the  limits 
imposed  by  a  criterion  or  set  of  criteria)  for  the  operation 
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of  the  system"  (Shannon  1975).  In  discussing  the  simulation 
process  most  texts  and  articles  (Banks  and  Carson  1984; 

Gordon  1978;  Law  and  Kelton  1982;  Schmidt  1985;  Shannon 
1975;  and  others)  outline  a  series  of  steps  "to  guide  a  model 
builder  in  a  thorough  and  sound  simulation  study"  (Banks  and 
Carson  1984).  An  example  from  Shannon  (1975)  is  shown  in 
Figure  1 . 

Depending  on  the  emphasis  of  the  book/article,  each  of 
the  steps  are  discussed  in  varying  levels  of  detail.  Texts 
generally  focus  on  the  more  technical  aspects,  such  as  prog¬ 
ramming  and  statistical  analysis  of  input/output  data.  The 
more  subjective  aspects  of  the  process,  such  as,  problem  def¬ 
inition,  identifying  objectives,  system  definition,  and  how 
to  go  about  collecting  this  information  and  other  data,  often 
receive  very  little  attention.  This  is  meant  to  be  more  of 
an  observation  than  a  criticism,  because  it  makes  sense  to 
spend  the  most  time  on  concepts  that  are,  for  the  most  part, 
new  to  a  student.  It  is  felt,  however,  that  this  can  result 
in  a  skewed  perception  of  what  a  simulation  study  is,  or  why 
a  study  is  undertaken. 

Shannon  (1975)  and  to  a  degree  Martin  (1968)  do  provide 
a  more  expanded  discussion  of  some  of  these  more  subjective 
aspects.  Shannon  particularly  focuses  on  simulation  as  a 
complete  process,  i.e.,  the  study  is  not  done  until  its 
results  are  accepted  and  implemented.  He  also  discusses  the 
political  aspects  of  having  the  results  of  a  study  accepted 
by  the  decision  makers.  Shannon  (1975)  does  acknowledge  that 


texts  do  a  poor  job  in  these  areas.  He  states: 


Every  study  involves  data  gathering.  Data  gather¬ 
ing  is  usually  interpreted  to  mean  gathering  numbers 
but  the  gathering  of  numbers  is  only  one  aspect 
of  data  gathering.  The  system  analyst  must  be  con¬ 
cerned  with  data  regarding  the  inputs  and  outputs 
of  the  system  he  is  studying  as  well  as  information 
about  the  various  components  of  the  system  and  the 
interconnections  or  relationships  between  them.  He 
is  therefore  interested  in  gathering  both  quantita¬ 
tive  and  qualitative  data,  and  he  must  decide  what 
data  are  needed,  whether  they  are  pertinent, 
whether  existing  data  are  valid  for  his  purpose,  and 
how  to  gather  this  information.  Textbooks  usually 
give  the  student  all  of  the  pertinent  information 
and  data  without  reference  to  how  it  was  gathered 
and  validated.  The  student  then  becomes  schizophrenic 
when  faced  with  his  first  unstructured  problem  for 
which  he  must  determine  on  his  own  what  data  are  needed 
and  how  to  gather  them. 


It  was  this  reality  which  motivated  this  research.  It 
was  first  felt,  that  while  better  and  more  structured  proced¬ 
ures  were  needed,  the  primary  solution  would  be  more  know¬ 
ledge  and  experience.  However,  continued  research  soon 
showed  that  people  experienced  in  the  field  were  identifying 
poor  methodology  and  procedures  as  a  problem  and  were  looking 
for  a  better  way  to  conduct  simulation  studies. 


Problem  --  A  Broader  View 


Beginning  in  the  late  1970s  there  was  acknowledgement 
in  the  field  that  recurring  problems  were  the  result  of  poor 
or  inadequate  procedures.  It  was  "apparent  no  one  is  worry¬ 
ing  about  the  total  simulation  methodology"  (Huhn  and  Comer 
1981).  Furthermore,  "Current  simulation  techniques  are 
highly  dependent  upon  the  experience  and  skill  of  those 


applying  them  and  do  not  provide  a  good  communication  tool. 
(Evers,  Backert,  and  Santucci  1981),  and  "The  primary 
difficulty  with  computerized  models  is  traceable  to  the  lack 
of  discipline  and  control  in  the  development  stages  and  a 
reliance  on  nonexistent  or  outdated  planning  and  project 
management  aids"  (Nance,  Mezaache,  and  Overstreet  1981). 

Additionally,  Miller  and  Pare  (1986)  point  out  that 
trends  in  the  use  of  simulation  "demand  new  and  more 
sophisticated  techniques  to  execute  and  manage  modeling 
projects."  These  included  the  trend  for  simulation  systems 
to  support  multiple  phases  of  a  project  development  and  a 
more  extensive  use  of  a  model  to  support  decision-making. 
This  in  turn  resulted  in  longer  life  spans  for  simulations. 
Another  trend  was  for  the  "user"  of  simulations  to  be  "a 
person  with  functional  expertise  in  the  area  being  modeled 
but  no  simulation  or  programming  background."  This 
requires  the  system  to  be  very  user-friendly  as  well  as  have 
"automation  of  the  statistical  analysis  and  data  base 
management . " 

More  specifically,  Zeigler  (1979)  stated  that  "contem¬ 
porary  simulation  methodology  is  inadequate  for  handling 
large-scale  multi-faceted  systems"  and  identifies  three 
"limitations  of  conventional  simulation  techniques": 

1.  Impediments  to  facile  communications:  man-man, 
man-machine  --  Models  are  difficult  to 
construct  for  the  time  being,  in  part  because 
the  computer  offers  too  little  help  in  develop¬ 
ing  models  and  verifying  simulation  programs. 

2.  Inadequate  conceptual  framework  --  The 
distinct  functional  elements  involved  in 
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simulation  are  not  clearly  distinguished  by 
conventional  simulation  languages. 

Lack  of  necessary  software  tools  and  data 
structures  for  organizing  models  and  their 
data  --  Facilities  for  subdividing  the  model 
into  modules  and  for  organizing  them  hier¬ 
archically  to  form  a  working  model  are 
necessary  to  speed  the  construction  of  new 
models  from  existing  ones. 


Nance,  Mezaache,  and  Overstreet  (1981)  state  that  "diffi¬ 
culty  stems  from  the  missing  ingredient:  model  management". 
Huhn  (1981)  says  "A  preoccupation  exists  in  the  selection 
of  a  simulation  language  before  the  system  problem  and  its 
model  are  understood.  The  classic  problem  is  in  the  attempt 
to  use  a  simulation  language  to  express  the  system  model, 
and  the  basic  problem  is  "there  is  no  established  methodology 
for  characterizing  a  system  as  a  model". 

Whatever  the  reason,  though,  analysts  and  simulations 
were  not  providing  useful  results  (Annino  and  Russell  1979; 
Huhn  and  Comer  1981;  and  Nance,  Mezaache,  and  Overstreet 
1981).  Annino  and  Russell  (1979)  pointed  out  that  the  key  "to 
successful  use  of  simulation  analysis  lies  in  understanding 
and  applying  new  methodologies."  The  next  section,  there¬ 
fore,  will  look  a  little  closer  at  some  of  these  "new" 
methodologies . 


Methodologies 


Methodologies  are  "bodies  of  concepts,  approaches,  and 
methods"  which  seek  to  not  only  define  what  has  to  be  done 
but  how  to  go  about  doing  it  (Zeigler  1979).  For  example,  a 
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step  in  the  simulation  process  is  to  describe  or  define  the 
system  to  be  modeled.  A  methodology  will  give  you  a  way  to 
do  this.  Tools  or  computer  software  will,  in  turn,  make  this 
methodology  easier  to  accomplish. 

In  briefly  discussing  this  topic  we'll  use  four  of  five 
were  categories  of  approaches  suggested  by  Nance  (1979). 

These  "(1)  extension  of  software  development  techniques,... 
(3)  extension  of  SPL  (Simulation  Program  Languages)  defini¬ 
tion,  (4)  system  specification  languages,  and  (5)  model-based 
methodology." 

The  first  has  to  do  with  the  idea  that  the  output  of  a 
simulation  study  is  software.  Thus,  the  programming  and 
software  development  procedures  and  tools  offer  all  that  is 
necessary  (Huhn  and  Comer  1979;  Miller  and  Pare  1986;  and 
Golden  1985).  These  references  actually  do  more  than  just 
advocate  the  use  of  software  techniques  to  aid  in  the  devel¬ 
opment  and  management  of  simulation  projects.  They  are 
realistic  enough  to  realize  it  will  take  a  combination  of 
techniques.  Huhn  and  Comer  advocate  an  Integrated  Software 
Methodology  (ISOMET)  which  provides  "a  collection  of  inte¬ 
grated  policies,  procedures,  standard  practices,  and  guid- 
lines  which  provide  increased  productivity  and  management  of 
the  software  development  process."  Miller  and  Pare  (1986) 
view  the  process  as  software  development  but  have  developed  a 
methodology  based  on  software  development  techniques  and 
simulation  techniques  based  on  Shannon  (1975),  Nance  (1981), 
and  Huhn  and  Comer  (1981).  While  such  techniques  come  under 


some  minor  criticism  from  the  simulation  community,  they  do 
attempt  to  offer  a  more  structured  approach  to  the  simulation 
process . 

The  SPL  approach  involves  using  the  simulation  language 
as  a  framework  for  modeling  the  system.  This  approach  has 
been  a  great  aid  in  simplifying  the  task  of  programming  the 
system  model  but  also  has  resulted  in  the  system  model  being 
constrained  by  the  world  view  of  a  particular  language 


(Nance  1983).  Nance  cites  the  fact  that  the  number  of 
models  programmed  in  higher  level  languages  such  as,  FORTRAN, 
and  Pascal,  "emphasizes  the  perceived  difficulties  of  trans¬ 
lating  modeling  concepts  into  a  correct  SPL  representations." 

The  system  specification  languages,  or  more  broadly 
SPL's  are  "based  explicitly  on  systems  theoretic  concepts  and 
the  development  of  conceptual  and  mathematical  theories  for 
guiding  the  practice  of  modeling  and  for  designing  software 
tools..."  and  offer  advantages  over  current  approaches  (Nance 
1983;  Zeigler  and  Oren  1979).  For  simplicity,  the  fourth 
approach,  the  model  based  approach,  will  be  included  in  this 
discussion  because  both  are  predicated  on  separating  the 
"functional  elements"  of  conventional  simulation  programs 
into  autonomous  modules  so  each  can  be  worked  with  separate- 


Both  also  depend  on  an  extensive  database  management 
system  in  which  data  regarding  these  functional  elements  are 
stored.  Zeigler  and  Oren  (1979)  categorized  the  data 
requirements  into  four  different  files:  "(1)  experimental 


TOW 


6 


frame  files"  which  includes  "initial  conditions,  end-of-run 
criteria,  and  output  variables;  (2)  model  file  which  includes 
"model  structure  and  model  output  specifications  so  you  can 
combine  a  given  model  structure  with  different  model  outputs 
to  have  different  models  of  the  same  system";  (3)  model  data 
files  which  contain  the  data  collected  from  the  computer 
runs;  and  (4)  the  Real  System  data  file  which  includes  data 
gathered  from  the  system  under  study  to  aid  in  model  building 
(Standridge,  1981;  Zeigler  and  Oren,  1979). 

Similarly,  Nance  (et  al.  1981)  outlines  the  components 
for  a  model  management  system.  They  are  "(1)  a  data  base 
management  subsystem,  (2)  an  extensive  dialogue  module 
providing  the  vehicle  for  producing  a  communicative  model 
from  a  conceptual  model,  (3)  a  software  development 
subsystem,  (4)  a  documentation  production  subsystem,  (5)  an 
experimental  subsystem,  and  (7)  an  internal  monitoring  and 
accounting  subsystem."  Again,  of  prime  importance  is  the 
"functional  partitioning". 

In  1983  Nance  (1983)  discusses  this  concept  in  terms  of 
of  a  Model  Development  Environment  (MDE)  which  would  "provide 
an  interactive  setting  for  model  creation  so  that  the 
modeling  activities,  supported  by  necessary  model  development 
tools,  contribute  to  long  term  organization  assets  in  the 
form  of  models,  data,  experimental  designs,  and  experimenta¬ 
tion  results."  Whether  this  is  an  extension  of  the  model 
management  system  is  not  known,  but  it  does  provide  a  simple 
statement  of  the  type  of  computer  support  required  of  the 


system  or  model-based  methodologies.  The  next  section  will 
look  at  this  aspect. 


Simulation  Support  Systems 


This  section  will  look  at  simulation  support  systems  and 
focus  on  integrated  support  systems  as  defined  in  chapter  1. 
As  an  example  we'll  look  at  The  Extended  Simulation  System 
(TESS  -  Pritsker  and  Associates). 

Standridge  (et  al.  1985)  describes  four  generations  of 
simulation  software.  The  first  generation  includes  "languages 
such  as  Q-GERT  and  GASP  II  which  provided  a  single  world  view 
for  constructing  models."  The  second  generation  involved 
extensions  of  the  first,  and  allowed  for  more  than  one  world 
view  in  a  single  language.  Examples  of  this  type  of  software 
includes  SLAM  and  GASP  IV.  The  third  generation  "recognized 
that  software  was  needed  to  support  other  aspects  of  a 
simulation,  beyond  the  model  conception  and  implementation 
provided  by  simulation  language."  Examples  here  include 
AID  and  UNIFIT  for  fitting  input  data  to  distributions,  SDL 
for  managing  the  data  of  simulations,  and  SIMCHART,  SEE  WHY 
and  SIMAN  for  graphical  presentation  of  simulation  results. 

In  a  separate  article,  Standridge  (1985)  points  out  that 
applications  showed  "the  value  of  having  support  systems"  and 
also  "established  the  usefulness  of  separating  the  analysis 
and  presentation  of  simulation  results  from  the  simulation 
run  as  well  as  separating  the  analysis  results  from  their 
presentation.  In  addition,  benefits  of  data  base  management 
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techniques  to  organize  and  select  simulation  model  inputs  and 
results  were  established-  The  ability  to  automatically  col¬ 
lect  data  during  simulation  runs  was  established.  In 
presenting  simulation  results,  especially  to  nonsimulation 
experts,  the  usefulness  of  graphics  (including  the  animation 
of  simulation  runs)  was  demonstrated." 

These  concepts  are  really  the  basis  of  the  methodologies 
described  above,  and  an  integrated  environment  incorporating 
these  concepts  represents  the  fourth  generation.  TESS  is  an 
example  of  this  type  of  software.  It  would  also  seem 
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appropriate  to  include  some  of  the  interactive  graphically 
animated  systems,  such  as,  Cin ima /S IMAN ,  AUTOGRAM,  and  RTCS 
(Grant  and  Weiner  1986).  However,  TESS,  and  to  a  certain 
extent  SIMPLE_1  purport  to  be  integrated  systems.  TESS  will 
therefore  provide  the  basis  of  the  remainder  of  this  discus¬ 
sion. 

Table  1  outlines  the  specifications  upon  which  TESS  is 
built  (Pritsker  1986;  Standridge  1983;  and  Standridge 
1985)  and  Figure  2  shows  the  TESS  architecture  (Standridge, 


Vaughan,  and  Sale  1985).  Essentially,  "TESS  provides  a 
framework  for  performing  simulation  studies"  (Standridge, 
1985).  It  is  described  as  a  generic  system  and  can  currently 
support  SLAM  II,  MAP/I,  and  GPSS/H  simulation  languages 


(Pritsker  1986).  To  briefly  show  what  TESS  can  do,  table 
3  lists  some  of  its  capabilities  (Standridge,  et  al.  1985). 


TABLE  1 


SUPPORT  SYSTEMS  SPECIFICATIONS 


A  Simulation  Support  System: 

Must  support  model  building. 

-  Must  provide  an  environment  for  the 
analyst  to  remodel. 

-  Models  should  be  easily  recalled  and 
categorized . 

-  Model  building  should  be  interactive  and 
graphical . 

-  A  documentation  trail  regarding  model 
development  should  be  maintained. 

Must  support  the  data  management  tasks,  to 
include  storage,  retrieval,  and  organization 
of  system  data,  experimental  control 
specifications,  and  simulated  generated 
output . 


-  The  simulation  outputs  should  reference 
both  the  experimental  specifications 

and  the  model  from  which  it  is  generated. 

-  Procedures  are  required  to  assess,  edit, 
concatenate,  and  display  data  stored  in 
the  data  base. 

-  It  is  also  useful  to  be  able  to  assess 

the  simulation  outputs  for  presentation  in 
spreadsheets  or  as  inputs  to  other  models. 

-  Once  in  the  database,  the  form  of  the 
simulation  data  should  not  differ  from  the 
form  of  the  actual  system  data. 


Must  support  analysis  and  reporting  tasks. 

-  It  is  necessary  to  estimate  the  dry-up  or 
close-down  time  for  system  operation. 

-  Procedures  for  interrogating  data  obtained 
from  a  simulation  run  are  needed  to  explore 
such  situations  within  runs  and  over  multiple 


(Pritsker  1986;  Standridge  1983;  and  Standridge, 
Vaughan,  and  Sale  1985) 
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Language 


Scenario 

Simulation/ 

Data 


Control 

Management 


Network 


Management 


Reports  & 
Graphics 
Generation 


Scenario 


Animation 


Data 

FORTRAN 

Storage  & 
Retrieval 

Subroutines 

TABLE  2 


TESS  CAPABILITIES 


TESS  Provides : 

A  framework  for  problem  solving  using 
simulation . 

Separation  of  the  analysis  and  presentation 
of  simulation  results  from  their  genera¬ 
tion  in  simulation  runs. 

Integration  of  modeling  and  simulation 
execution  with  reporting,  graphing  and 
analysis  capabilities. 

A  command  language  to  access  each 
capability  used  in  problem  solving. 

Creation  and  management  of  network  models. 

Independent  specification  of  experimental 
conditions  for  controlling  simulation  runs 
(CONTROLS). 

Management  of  user  defined  data. 

Procedures  for  combining  CONTROLS,  data 
and  models  to  specify  alternatives  called 
SCENARIOS. 

A  report  generator  for  presenting  simu¬ 
lation  results  and  other  data. 

Graphing  of  networks,  simulation  results 
and  user  defined  data. 


Procedures  for  dynamically  presenting  the 
operation  of  a  model,  that  is,  the  anima¬ 
tion  of  simulation  results. 

Computation  of  frequency  distributions  and 
statistics  as  well  as  estimation  of 
confidence  intervals. 

Support  for  database  management  tasks. 


(Standridge,  Vaughan,  and  Sale  1985) 
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CHAPTER  3 


THE  SIMULATION  PROCESS 


Before  a  suitable  methodology  could  be  developed  it  was 
first  necessary  to  get  a  better  understanding  of  the  process, 
especially  the  initial  phases.  This  chapter  reviews  the 
procedure  that  was  used  in  developing  a  more  detailed  break¬ 
down  of  the  initial  phases  of  a  simulation  study. 

Approach 

In  analyzing  the  simulation  process,  "structured 
analysis"  was  selected  as  a  method  by  which  to  provide  a  more 
organized  approach.  Structured  analysis  (Weinberg  1979)  "is 
a  disciplined  approach  to  structuring  the  system  analysts 
job."  Because  of  the  variety  of  functions  and  of  systems 
development  phases  in  which  the  system  analyst  is  involved, 
structured  analysis  is  defined  as  a  philosophical,  top-down 
approach  to  all  phases  of  the  systems  life  cycle."  This 
methodology  net  only  addresses  the  "different  phases  of 
systems  development  in  the  form  of  a  structured  methodology 
but  also  the  cc mmun  icat i ons  and  coordination  between  phases 
required  to  make  the  development  a  success." 

The  stiuctured  analysis  methodology  utilizes  a  bubble 
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action  and  arrows  leading  in  and  out  representing  inputs  and 
outputs  for  that  action.  Arrows  can  also  represent  required 
communications. 


By  considering  the  simulation  process  as  a  system,  the 


Figure  4.  Structured  Analysis  Diagram 
(Weinberg  1979) 


task  was  to  analyze  the  system,  identify  subsystems,  and  the 
interactions  between  them.  The  idea  was  to  start  very  broad 
and  general,  and  work  towards  a  more  detailed  and  specific 
description . 


The  Process-General  Description 

In  its  most  basic  form  the  simulation  process  is  a 
system  with  a  user  problem  being  the  primary  input  (a  reason 
for  conducting  the  study)  and  a  solution  to  that  problem 
being  the  primary  output.  Available  knowledge  about  the 
problem  and  system  to  be  modeled  is  also  a  required  input. 
Additional  knowledge  about  the  problem  and  system  is  another 
output.  Figure  5  represents  this  basic  system  (Zeigler 
1979  and  Shannon  1975). 


Figure  5.  The  Basic  Simulation  Process 


The  success  of  this  process  as  well  as  the  way  it  will 
be  further  broken  down  is  predicated  on  several  concepts 
discussed  by  the  above  referenced  sources  and  others  (see 
reference  section).  First,  and  most  obvious,  is  that  the 
quality  of  the  simulation  process  is  only  as  good  as  the  in 
puts,  the  simulation  model,  and  its  output.  This  really 
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Figure  6.  Influence  of  External  Factors  on 
T  h  2  Simulation  Process. 


entails  the  quality  of  input  and  output  data,  and  the 
validity  of  the  model. 


Second,  a  simulation  process  is  a  project  which  must  be 


managed  and  like  all  projects  is  subject  to  various 


constraints  and  external  factors  (see  Figure  4)  (Kerzner 


1984).  These  external  factors  are  important  because  they  may 


impact  on  the  feasibility  of  using  simulation  and/or  the 


acceptance  of  the  study,  irrespective  of  its  quality.  The 


goal  should  therefore  be  to  internalize  these  factors  into 


the  process. 


Third,  the  simulation  process,  in  Figure  1  and  other 


sources,  is  normally  described  as  an  iterative  process. 


Pritsker  (1986)  states  "The  stages  of  simulation  development 


.  .  .  are  rarely  performed  in  a  structured  sequence  beginning 


with  problem  definition  and  ending  with  documentation.  A 


simulation  project  may  involve  false  starts,  erroneous 


assumptions  which  must  later  be  abandoned,  reformulation  of 


the  problem  objectives,  and  repeated  evaluation  and  redesign 


of  the  model.  If  properly  done,  however,  this  iterative 


process  should  result  in  a  simulation  model  which  properly 


assesses  alternatives  and  enhances  the  decision-making  proc- 


Finally,  now  that  this  third  concept  has  been  stated,  is 


the  concept  or  thesis  that  if  many  of  the  problems  common  to 


simulation  studies  are  to  be  avoided,  a  more  structured 


approach  must  be  taken.  It  does  not  seem  reasonable  to  start 


model  development  without  a  clear  and  accepted  definition  of 
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the  problem  and  the  objectives  to  be  attained.  Also,  the 
system  to  be  modeled  must  be  properly  defined.  Certainly, 
whatever  approach  is  taken,  it  must  be  flexible.  Every 
problem  solution  method  is  iterative  in  that  you  are 
continually  discovering  more  facts  and  data.  (This 
concept  implied  but  never  actually  stated  in  the  following: 
Barnes  1968;  Evers,  Bachert,  and  Santucci  1981;  Miller  and 
Pare  1986;  Martin  1968;  Huhn  and  Comer  1981;  Schmidt 
1985;  Weinberg  1979). 

With  these  concepts  in  mind  the  next  step  was  to  start 
defining  subsystems  beginning  with  a  structure  which  resulted 
in  some  sequence  of  actions  with  the  output  of  one  subsystem 

TABLE  3 


PHASES  OF  THE  SIMULATION  PROCESS 
ACCORDING  TO  BANKS  AND  CARSON 


Phase 

Step 

IS 

1 

1  . 

Problem  Formulation 

2. 

Setting  of  Objectives 
and  Overall  Design 

2 

3. 

Model  Building 

4. 

Data  Collection 

5. 

Coding 

6. 

Verification 

7  . 

Validation 

3 

8. 

Experimental  Design 

9. 

Production  Runs  and 
Analysis 

10. 

Additional  Runs 

4 

1  1  . 

Documentation  of  Prograi 
and  Report  Results 

12  . 

Implementation 

(Banks  and  Carson,  1984) 
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representing  the  input  of  the  next  subsystem.  Martin  (1968) 
defined  the  process  as  three  phases;  developing  the  concep¬ 
tual  model,  model  implementation,  and  model  results.  Banks 
and  Carson  (1984)  divided  their  12  step  process  into  four 
phases  as  shown  in  Table  3. 

Combining  these  concepts  and  ideas  from  other  sources 
the  system  was  expanded  into  six  subsystems,  or  phases,  (see 
Figure  7).  While  ideal  in  nature,  the  output  of  each  phase 
is  the  input  of  the  subsequent  phase.  This  further  implies 
that  a  phase  must  be  completed  prior  to  beginning  the  next 
one.  Also,  while  the  iterative  nature  of  the  process  is  not 
shown,  this  concept  is  evident  within  each  phase. 

The  process  begins  with  an  investigation  and  analysis  of 
the  problem.  The  outcome  of  this  phase  is  knowledge  about 
the  problem  and  system.  This  includes  (ideally)  an  explicit 
definition  of  the  problem,  explicit  goals  and  objectives  to 
be  accomplished  by  the  study,  constraints  and  limitations, 
information  and  data  defining  system  operation,  and  a  static 
definition  of  the  system.  This  data  should  be  validated  with 
the  user/sponsor  and  a  preliminary  cost/benefit  analysis 
conducted.  All  key  decision-makers,  system  experts,  or 
others  that  may  influence  the  study  or  its  outcome  should  be 
identified,  along  with  sources  of  data  and  information. 

As  shown  in  Figure  7,  a  detailed  investigation  of  the 
problem  and  system  may  result  in  an  acceptable  solution  to 
the  problem.  Not  shown  though,  is  that  this  phase  is  really 
carried  on  throughout  the  entire  process.  In  a  more 
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Figure  7.  Flow  Diagram  —  Simulation  Process 


structured  sense,  this  phase  may  be  divided  into  two  phases; 
a  preliminary  investigation  prior  to  project  planning  and  a 
more  detailed  investigation  following  project  approval  when 
funding  and  additional  manpower  may  be  available.  The  pre¬ 
liminary  goal,  however,  is  to  complete  the  phase  prior  to 
beginning  extensive  modeling  and  programming. 

Phase  2  involves  using  the  knowledge  gathered  in  phase 
1  to  develop  a  conceptual  model  then  develop  and  evaluate 
alternatives  for  how  to  implement  this  model.  Then  having 
decided  that  simulation  will  be  the  appropriate  modeling 
methodology,  a  detailed  plan  and  proposal  for  how  to  conduct 
this  study  is  developed  and  presented  to  the  user /sponsor . 
This  insures  that  the  problem  and  objectives  are  understood 
both  by  the  user  and  the  analyst,  each  understands  what  will 
be  expected  from  the  other,  and  what  will  and  will  not  be 
achieved  by  the  study.  Also,  the  time  and  cost  constraints 
are  accounted  for  and  a  detailed  cost/benefit  analysis  com¬ 
pleted.  Finally,  detailed  project  requirements/specifica¬ 
tions  should  include  preliminary  planning  for  how  the  model 
will  be  implemented,  strategic  and  tactical  planning,  and 
experimental  design. 

Phase  3  is  the  actual  development  of  a  model  which  is 
translated  to  computer  code.  It  is  during  this  phase,  after 
input  data  requirements  have  been  firmly  defined  that  this 
type  of  data  is  collected.  The  output  of  this  phase  is  a 


valid  model,  accepted  and  understood  by  the  use r / s pon so r  . 
Phase  4  is  where  the  model  is  actually  implemented. 
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Detailed  experimental  design,  and  strategic  and  tactical 
plans  are  completed  and  simulation  runs  conducted.  It  is 
here,  as  well  as  with  the  collection  of  input  data,  that 
additional  trade-offs  may  have  to  be  made  because  remaining 
funds  and  time  may  limit  the  number  of  experiments  that  may 
be  conducted.  This  may  result  in  a  lower  level  of  accuracy 
and  detail.  It  is  therefore  important  for  these  issues  to  be 
considered  during  the  project  planning  phase  and  accounted 
for  in  the  project  budget  (Shannon  1975). 

Phases  5  and  6  involve  analyzing  the  results  and 
developing  recommendation  for  the  user,  and  preparing 
documentation  of  the  study.  The  ultimate  outcome  is  a  solu¬ 
tion  for  the  original  problem. 

Utilizing  the  structured  analysis  technique  each  phase 
was  further  subdivided  with  the  level  of  detail  increasing 
at  each  successive  level.  Again,  the  purpose  of  this 
breakdown  was  to  develop  an  understanding  of  the  simulation 
process  and  put  into  perspective  what  goes  on  in  the  early 
phases  of  the  simulation  process;  primarily  subsystem,  or 
phase  1,  figure  7. 

Specifically,  the  tasks,  data  to  be  collected  and  arch¬ 
ived,  and  sources  for  this  data  needed  to  be  identified.  The 
results  of  this  analysis,  as  it  relates  to  the  two  major  data 
outputs  of  phase  1,  problem  definition  and  system  definition, 
are  summarized  in  Tables  4  and  5.  This  information  was  then 
used  to  develop  a  generic  "support-support"  system  specifica¬ 
tion  which  will  be  discussed  in  the  next  chapter. 
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TABLE  4 


PROBLEM  FORMULATION  SUMMARY 


TASK 

Schedule  Interview 
Plan  Interview 
Conduct  Interviews 
Conduct  Research 
Observe  System 
Operation 
Analyze  Data/Info 
Prepare  and  Submit 
Periodic  Updates 
to  Users  for 
Validation 


DATA 


Key  Decision-makers  P 

Key  Managers  K 

Users/Experts 
Important  Sources  S 

of  Information  D 

Communicated  Problem  0 

Operating  Policies  P 

Perceived  Benefits  of 
Solving  Problem  or 
Obtaining  Additional 
Information 
Objectives  (of  system 
and  key  decision¬ 
makers  and  managers 
Criteria  to  measure 
Objectives 

Constraints/Limitations 
On  System 

Constraints/Limitations 
On  Study 

Expectation  of  Users 
Factors  Affecting  System 
Assumptions/Hypothesis 


SOURCE 

Project  Sponsor 
Key  Decision¬ 
makers 

System  Experts 
Documents 
Observing  System 
Participating  in 
System 

Operation 


TABLE  5 

SYSTEM  DEFINITION  SUMMARY 


TASK 

Schedule  Interview 
Plan  Interview 
Conduct  Interviews 
Conduct  Research 


DATA 

System  Environment 
Environment  Factors 
System  Components  & 
and  Subcomponents 


SOURCE 

System 

Documents 

Users/Experts 

Managers 


Observe  System 
Operation 

Develop  a  Schematic 
Static  Represent¬ 
ation  of  System 

Present  Findings 
to  Users  and 
Validate  system 
Definition 


Inputs  and  Outputs 
for  These 
Components  and 
Subcomponents 

Assumptions  and 
Hypothesis 


Documents 

System  Designers 

Participating  and 
Observing 
System 
Operation 


CHAPTER  4 
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GENERIC  SPECIFICATION 

This  chapter  will  outline  the  specification  for  a  gener¬ 
ic  "support-support"  system.  The  first  section  will  discuss 
the  general  concept  of  a  support-support  system.  The  second 
section  will  identify  the  major  functions  such  a  system 
should  support,  and  the  last  section  will  outline  general 
system  requirements. 

To  simplify  terms,  the  remainder  of  this  report  will 
refer  to  the  support  system  as  discussed  in  Chapter  2  (TESS) 
as  the  primary  support  system.  The  system  being  proposed 
will  simply  be  referred  to  as  the  support  system. 

Basic  Concept 

Based  on  the  breakdown  produced  in  Chapter  3,  the 
proposed  support  system  should  support  all  aspects  of  phase 
1  and  task  3.4  in  phase  5  (collect  input  data).  The  primary 
support  system  as  defined  in  Chapter  2  appears  to  be  capable 
of  supporting  phases  3-6,  with  the  exception  of  3.4,  and  most 
of  phase  2. 

The  primary  purpose  of  this  support  system  will,  there¬ 
fore,  be  to  support  the  data  collection  aspects  of  a  simula¬ 
tion  study.  Detailed  analysis  of  this  data  will  occur  in  the 
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primary  support  system.  However,  the  proposed  support  system 
needs  to  provide  for  enough  analytical  ability  so  the  analyst 
can  adjust  the  collection  effort  as  problems  arise  or  new 
information  becomes  available. 

In  general,  the  support  system  is  to  help  in: 

1.  organizing  and  guiding  the  collection  effort; 

2.  organizing  and  archiving  the  data; 

3.  displaying  the  data  for  review,  analysis,  update, 
and  validation;  and 

4.  Producing  required  reports. 

The  goal  of  the  proposed  system  is  to  insure  the  data  (both 
subjective  and  objective)  necessary  to  perform  a  simulation 
project  is  gathered  in  as  efficient  and  effective  manner,  and 
the  problems  common  to  many  projects  be  avoided. 


Ma  ior  Functions 


The  proposed  support  system  should  provide  help  in  four 
major  areas  and  two  minor  areas  as  shown  in  Figure  8.  The 
major  functions  consist  of  problem  definition,  system 
definition,  input  data  collection,  and  project  planning  and 
management.  The  minor  functions  support  the  other  four  and 
are  economic  analysis  and  report  generation.  This  section 
will  briefly  discuss  these  6  functions. 

Formulate  Problem.  The  support  system  should  aid  in 
the  orderly  collection  of  data  necessary  to  define  the  prob¬ 
lem.  Table  4  shows  the  tasks  and  information  applicable  to 
this  function. 

The  problem  definition  will  consist  of  4  issues.  The 


Figure  8.  Support-Support  System  Architecture 

first  is  a  workable  definition  of  the  problem  as  communicated 
to  the  analyst  by  the  users.  Often  times  the  only  thing 
people  are  sure  about  is  the  fact  there  is  a  problem.  The 
analyst  will  start  with  a  list  of  symptoms  and  have  to  iden¬ 
tify  the  underlying  causes.  The  second  is  to  take  into 
account  the  politics  of  the  organization  as  it  relates  to  the 
problem  and  its  solution.  That  is  why  it's  important  to 
identify  and  interview  all  key  people  who  can  add  to  the 
understanding  of  the  problem,  and  also  affect  the  implemen¬ 
tation  of  the  solution.  Third,  is  to  determine  the  benefits 


that  will  result  from  solving  the  problem.  This  is  closely 
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related  to  the  fourth  issue.  What  it  will  take  to  solve  the 
problem;  both  in  terms  of  methodology,  manpower,  and  money? 
Normally,  if  the  cost  of  solving  the  problem  is  more  than  the 
benefits,  there  is  little  reason  to  continue  the  project. 

The  data  will  be  collected  from  numerous  sources,  but 
the  primary  method  will  be  by  interviewing  key  decision¬ 
makers,  managers,  and  system  operators  (experts).  Other 
sources  include  observation,  and  researching  applicable 
regulations,  procedures,  manuals,  and  policy  statements.  Of 
interest  also,  is  whether  any  previous  studies  have  been 
accomplished  concerning  the  problem.  These  previous  studies 
can  provide  valuable  insight  into  both  the  problem  and 
politics  of  solving  the  problem. 

System  Description.  The  system  should  aid  in  developing 
a  thorough  and  accurate  understanding  and  description  of  the 
system  to  be  modeled.  Table  5  shows  the  tasks  and  data  asso¬ 
ciated  with  this  function. 

The  support  system  should  provide  various  methods  to 
schematically  represent  the  system.  This  is  necessary 
because  different  systems  require  different  methods  and  dif¬ 
ferent  analysts  may  prefer  one  method  over  another.  Also, 
a  combination  of  methods  may  be  required  to  adequately 
describe  the  system  operation. 

The  support  system  should  provide  a  format  for  a  com¬ 
plete  verbal  description  of  the  system  operation  and  its 
respective  components,  to  include  inputs,  outputs,  and  fact¬ 
ors  influencing  its  operation. 
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Whatever  methods  are  used,  it  should  be  compatible  with 


or  translatable  to  the  modeling  tepresentation  used  by  the 
primary  support  system.  However,  the  primary  function  is  to 
obtain  knowledge  about  the  system  and  have  it  depicted  and 
described  in  such  a  fashion  that  this  knowledge  can  be  under¬ 
stood  and  validated  by  the  user's/sponsor. 

Input  Data  Collection.  The  system  should  aid  in  devel¬ 
oping  a  data  collection  plan  and  provide  formats  and  a  means 
for  collecting  this  data.  The  primary  support  system, 
through  the  modeling  process,  will  define  what  data  is  to  be 
collected,  but  the  proposed  support  system  should  help  in 
planning  where,  when,  and  how  to  collect  it.  It  should  also 
provide  a  means  to  archive  this  data  and  aid  in  inputting  it 
to  the  primary  support  system.  This  system  should  provide 
for  preliminary  analysis  of  the  data  to  insure  it  meets  the 
statistical  assumptions  of  independence  and  homogeneity. 
Finally,  the  system  should  provide  a  means  to  collect  data 
by  the  observing  system  operation  and/or  by  inputting  data 
from  documents. 

Project  Planner.  The  system  should  support  the  required 
planning  tasks,  both  personal  and  for  the  project  as  a  whole. 
The  project  planner  must  also  help  in  accounting  for  re¬ 
sources  expended  to  accomplish  the  project.  The  support 
system  should  also  help  in  developing  project  cost  estimates. 

Report  Generator.  This  function  will  support  the  other 
five.  The  system  should  provide  help  in  developing  all  re¬ 
ports  necessary  during  the  initial  phases  of  the  project. 
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Standardized  formats  should  be  developed  which  permit  the 
data  to  be  entered  as  it  becomes  available.  However,  the 
system  must  provide  the  flexibility  to  adjust  to  requirements 
of  the  particular  project  or  analyst. 

Economic  Analysis.  The  system  should  help  in  analyzing 
the  cos t / bene f i t s  of  solving  the  problem.  Coupled  with  the 
project  planner  function,  the  system  should  help  in  making 
many  of  the  trade-off  decisions  that  arise  during  the  course 
of  a  project.  This  includes  the  amount  of  data  to  be  col¬ 
lected.  Is  there  a  point  at  which  the  cost  of  collecting 
more  data/ inf ormation  overshadows  the  benefits? 


General  Support  System  Requirements 


The  support  system  should  support  the  iterative  nature 
of  this  phase  of  the  process.  While  the  simulation  process 
as  a  whole  is  an  iterative  process,  the  early  investigative 
phases  are  particularly  so.  Each  source  of  information  leads 
to  another. 

The  support  system  should  be  able  to  adapt  to  the  nature 
of  the  particular  project.  Each  problem  and  system  are  dif¬ 
ferent.  While  the  support  system  calls  for  a  more  standard¬ 
ized  and  structured  approach,  it  must  be  flexible. 

In  the  same  way,  the  support  system  should  take  into 
account  the  various  approaches  used  by  different  analysts. 
Whenever  possible,  the  support  system  should  provide  multiple 
formats  and  techniques  for  gathering  the  information. 

Data  collected  in  support  of  one  of  the  above  listed 
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functions  but  applicable  to  one  or  more  of  the  other  func¬ 
tions  must  be  identified  as  such  and  cross-referenced.  This 


is  to  prevent  the  analyst  from  collecting  the  same  data 


twice 


Finally,  the  support  system  should  insure  the  analyst 
considers  all  information  and  data  requirements.  Each  pro¬ 
ject  is  different  so  some  of  the  data  requirements  will  not 
be  applicable,  but  the  analyst  should  make  this  decision  and 
simply  not  overlook  it.  Also,  i n f o r ma t ion /da ta  requirements 
which  are  applicable  but  not  yet  defined,  should  result  in 
assumptions  and  hypothesis  concerning  the  data.  Then  the 
analyst  can  continually  review  and  update  these  assumptions 
as  information/data  becomes  available.  These  assumptions/ 
hypothesis  can,  in  turn,  help  the  analyst  develop  new  quest¬ 
ions  and  avenues  of  investigation. 


CHAPTER  5 


CONCEPT  FOR  IMPLEMENTATION 

This  chapter  will  examine  how  this  specification  can  be 
implemented  using  a  portable  microcomputer.  The  first  sec¬ 
tion  will  discuss  why  a  portable  microcomputer  should  provide 
a  suitable  platform.  The  second  section  will  suggest  how  the 
functions  defined  in  Chapter  4  can  be  implemented. 

For  the  most  part  this  implementation  strategy  is  still 
conceptual.  As  stated  in  Chapter  1,  this  study  resulted  in 
only  partial  implementation  of  the  input  data  collection 
function  which  will  be  discussed  in  more  detail  in  the  next 
chapter . 

Why  Use  A  Portable  Microcomputer 

While  a  workbook  or  guidebook  which  provided  the  appli¬ 
cable  checklists  and  formats  would  be  a  possible  alternative, 
a  computer  can  provide  the  same  features.  Most  important, 
the  purpose  of  the  system  is  to  collect  and  archive  data. 

The  computer  is  ideally  suited  to  this  task.  The  computer 
will  also  provide  the  flexibility  to  change  collection  and 
report  formats  to  meet  the  needs  of  the  project.  Finally, 
this  can  all  be  done  with  a  computer  you  can  fold-up  and 
carry  with  you  to  the  collection  site. 

Portable  microcomputers,  specifically,  the  Radio  Shack 
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Model  100,  and  special  electronic  data  collectors  have  been 
in  use  for  some  time,  particularly  for  work  measurement, 
work  sampling,  and  quality  and  inventory  control  (Savage  and 
Keevan  1984;  Wilkerson  1984;  and  Martin  1984).  These  devices 
especially  when  combined  with  the  office  PC,  have  reduced  the 
time  and  effort  to  conduct  these  studies  (McDermott  1984; 
Dossett  1984;  Sprague  and  Schoten  1984;  MacMillan  and  Walker 
1985;  and  Wilkerson  1984). 

Dossett  (1984)  points  out  that  these  collection  devices 
do  have  limitations,  though.  They  do  not  have  the  power  to 
develop  detailed  summaries  on  multiple  studies,  and  are  quite 
slow.  Also,  archiving  data  on  cassette  tape  is  a  problem. 
They  can  perform  certain  statistical  tests,  but  are  slow  and 
limited  in  what  they  can  do.  Furthermore,  these  devices 
don't  have  the  keyboards  and  screen  displays  for  more  power¬ 
ful  edi ting . 

Since  Dosset  first  made  those  observations,  the  portable 
data  collectors  have  improved.  They  are  faster,  and  can 
perform  more  statistical  tests.  They  are  small  and  can  port 
their  data  to  larger  computers  for  analysis.  They  are 
limited  in  the  type  of  data  they  can  collect  -  numeric  data. 

Though  not  hand-held,  some  of  the  newer  portable  micro¬ 
computers  are  small  and  light  enough  to  be  called  "laptop" 
and  have  capabilities  equal  to  the  desktop  PCs;  up  to  640K 
of  RAM,  dual  disk  drives,  full  80X25  c ha r a c t e r / 1 i ne  displays 
and  full  keyboards.  These  qualities  make  up  for  the  limit¬ 
ations  of  the  hand-held  devices  and  can  provide  the  capabil- 
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ity  to  support  all  aspects  of  the  data  collection  process. 

One  drawback  at  this  time  is  the  lack  of  readily  useable 
software.  Most  of  these  computers  use  the  3  1/2  inch  disks. 
They  can  hold  up  to  720K  data  but  there  is  not  as  much  soft¬ 
ware  available  in  the  3  1/2"  disk  size.  This  should  only  be 
a  temporary  problem,  though. 


Implementation  Strates 


Ideally,  to  implement  this  system,  a  single  software 
package  which  integrates  all  the  required  functions  is  neces¬ 
sary.  As  a  starting  point,  however,  this  study  suggest  that 
the  required  application  programs,  consisting  of  standard 
formats,  be  developed  using  generic  software,  such  as, 
spreadsheets,  database  managers,  word  processors,  and  pro¬ 
grams  written  in  BASIC.  Whenever  possible,  utility  programs 
should  be  written  to  integrate  the  different  functions. 

These  software  packages  are  readily  available  and  most 
potential  users  are,  at  least,  somewhat  familiar  with  their 
operation.  Also,  they  provide  the  user  the  maximum  flexibil¬ 
ity  to  adjust  them  to  his/her  own  desires  and/or  the  particu¬ 
lar  si tuation . 

Application  programs  should  be  run  in  drive  A  and  a  data 
disk  in  drive  B.  To  avoid  mixing  data,  a  data  disk(s)  should 
only  contain  data  from  one  project.  Also,  the  concept 
envisages  the  need  for  numerous  data  files.  Using  a  720K 
3  1/2"  disk,  the  user  is  limited  to  112  files.  If  subdirec¬ 


tories  are  used  then  the  number  of  files  are  limited  only  by 
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Figure  9.  Data  Disk  Directory 

the  amount  of  memory  on  the  disk.  A  tree  type  file  directory 
is  therefore  recommended  (Figure  9). 

The  remainder  of  this  section  provides  some  brief 
suggestions  on  how  each  system  function  could  be  implemented. 

Formulate  problem  -  Utilizing  a  word  processor  or  data 
base  manager,  formats  should  be  created  to  lead  the  analyst 
through  the  process  of  collecting  data.  A  data  base  manager, 
dBASE  III  would  appear  to  provide  the  most  flexibility, 
because  the  programmable  features  of  DBASE  III  would  allow 
the  analyst  to  input  both  the  formats  and  the  logic  to  guide 
him/her  through  the  process.  Database  files  could  be  created 
for  each  data  type  category. 

To  provide  a  basis  for  building  the  formats  and  logic, 
Balci  and  Nance  (1985)  offer  a  very  good  methodology  which 
lends  itself  to  computerization.  As  long  as  the  problem  can 
be  categorized  as  descriptive  or  prescriptive,  the  analyst 
follows  a  list  of  que s t ions/ i n f o r ma t i on  requirements  which, 
depending  on  the  outcome  of  each  step,  guides  the  analyst 
to  another  appropriate  ques t i on / i n f o r ma t i on  requirement. 
Figure  10  shows  a  flow  chart  which  depicts  the  procedure,  and 
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TABLE  6 
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JUSTIFY  THAT  THE  COMMUNICATED  PROBLEM 
IS  WORTHWHILE  TO  SOLVE 

<la>  If  it  fs  pen  ewed  that  a  set  of  <  urrenl < ondilums  deviate  from  ,i  range 
of  ac  editable  conditions  or  .1  desired  m-I  of  1  unditiom  go  lo  <ld> 

<lb>  tf  a  need  is  i>ercc»ivrd  to  olrtam  some*  return'd  information  lor  * l« ■«  • 
sion  making  go  In  <U*> 

<lc>  If  a  set  of  conditions  reflecting  no  sigmtic.ini  deviation  .10*  sought 
go  lo  <lt>:  otherwise  go  to  <tg> 

<ld>  Is  this  deviation  sign  1  tu  ant'  H  not  go  to  <lf*>  I  Jot’s  the  1  ompansnn 
of  potential  benefits  of  correcting  dm  deviation  vsiih  the  estimated 
cost  ot  correcting  it  pisfify  an  attempted  solution'  It  not  go  to  <lh> 
otherwise  go  to  Table  2 

<1o>  Does  the  comparison  of  potential  utility  »»t  ihis  information  vsith  ihe 
estimated  1  ost  ol  obtaining  it  pistify  obtaining  this  information'1  It  not 
go  lo  <Jh>,  others* ive  g t)  lo  Table  2 

<1f>  Ones  the  comparison  rrf  |»ntential  benefits  ot  tins  set  ol  « onditions 
with  the  estimated  cost  ot  actnesing  it  justify  the  attempt  to  olit.im 
this  set  of  comlilionsf  If  not  go  to  <lh>.  otherwise  go  to  Tjtile  2 

<lg>  Examine  the  context  of  the  communicated  problem  and  reexamine 
the  benefitVcosf  (B/O  ratio  to  |uslify  a  solution  afb  niftl.  (,o  to  T.ible  j 

<1h>  The  problem  is  not  worthwhile  lo  v»lve.  Tfie  solution  cost  is  likely 
lo  exceed  I  he  return  Terminate 

(Balci  and  Nance,  Table  1,  1985) 


TABLE  7 

IDENTIFY  ROOT  CAUSES  OF 
THE  COMMUNICATED  PROBLEM 


<2a>  Examine  the  symptoms  described  within  the  communicated  problem 
and  analyze  cauvdity  relationships  within  the  (  ontext  of  ihe  problem 
environment 

<2b>  list  and  label  all  the  symptoms,  problematic  situations  problems.  f.w. 
tors  and  conditions  that  alfect  each  other  m  causing  the*  com 
municated  problem 

Construct  a  causality  network  by  drawing  a  senes  of  edges  c  rossmg 
the  tatieled  elements  m  <Jb>  to  represent  how  they  relate  to  «*.»«  h 
-  Either  (One  can  contribute  to  another,  be  caused  by  another  or 
independent  of  another  ) 

<Jd>  Identify  the4oot  causes  as  ihe  ones  with  no  mdirre ted  edges 

<Je>  If  the  communicated  problem  requires  a  presc  riptive  solution,  go  to 
TaWe  5  If  it  requires  a  descriptive  solution  go  lo  Stage  10 

(Balci  and  Nance,  Table  2,  1985) 


Copy  available  to  DT1C  does  uai 
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Tables  six  and  seven  show  examples  of  the  steps  the  analyst 
would  follow  to  accomplish  each  phase  of  the  procedure. 

Refer  to  Balci  and  Nance  (1985)  for  additional  information. 
The  article  also  describes  a  questionnaire  type  procedure  for 
verifying  the  formulated  problem. 

Not  included  in  this  procedure  are  the  data  categories 
of  assumptions  and  hypothesis.  These  would  be  added  with  the 
logic  guiding  the  analyst  to  make  assumptions  and  hypothesis 
regarding  data  that  is  not  yet  known.  Then  as  information  is 
collected,  the  analyst  will  update  the  assumptions.  The  goal 
here  is  to  insure  the  analyst  considers  all  the  data  require¬ 
ments  . 

System  definition  -  This  function  will  involve  a  verbal 
description  of  the  system,  plus  a  means  to  schematically  de¬ 
pict  it.  Various  formats  for  doing  this  should  be  available 
to  the  analyst.  Shannon  (1975)  suggests  process  charts,  flow 
diagrams,  activity  charts,  and  block  and  logic  diagrams,  as 
possible  ways  to  help  describe  the  system  being  modeled. 
Pictorial  graphics  is  also  an  option.  Whichever  way  is  used, 
the  system  should  have  a  word  description  file  associated 
with  each  schematic,  so  as  the  schematic  is  created  or 
analyzed,  the  details  of  its  operation  can  also  be  entered/ 
reviewed . 

Project  planner  -  Numerous  project  planning  software 
packages  are  available.  The  choice  of  which  one  to  use  would 
be  up  to  the  user. 

As  stated  earlier,  a  simulation  study  is  a  project  and 
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must  be  managed.  A  project  planner  would  help  the  analyst  do 
this.  It  could  be  used  to  manage  the  personal  time  of  the 
analyst  and  project  staff.  It  could  also  be  used  to  estimate 
and  track  the  project  resources;  money,  manpower,  equipment 
and  time. 

A  standardized  project  format  needs  to  be  developed 
which  will  provide  a  starting  point.  The  analyst  can  then 
adjust  this  format  to  suit  the  needs  of  the  particular  pro¬ 
ject.  Also,  each  function  should  incorporate  a  utility  which 
logs  the  time  and  other  resources  expended  and  updates  the 
project  planning  files. 

Economic  analysis  -  The  primary  focus  of  this  function 
is  to  aid  in  conducting  cost/benefit  analysis  studies  of  the 
project.  Any  of  the  engineering  economy  software  packages 
will  suffice.  However,  coupled  with  the  project  planner  and 
a  decision  type  model  (Gray  1978)  this  function  can  help  in 
making  many  of  the  trade-off  decisions  that  arise  during  the 
course  of  a  project. 

Reports  generator  -  Standardized  report  formats  can  be 
developed  using  the  programming  portion  of  dBASE  III  or  a 
similar  data  base  manager.  Then  the  applicable  data  can  be 
merged  from  the  appropriate  files. 

Input  data  collection  -  The  system  needs  to  support 
collection  from  at  least  two  general  sources;  by  observing 
the  system,  and  from  documents. 

To  aid  in  collecting  data  from  documents,  a  program  is 
needed  to  help  the  analyst  build  collection  formats.  Then 
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the  data  can  be  entered  into  the  computer  as  these  documents 
are  reviewed.  The  required  formats  can  be  determined  during 
the  investigative  phase.  The  programmable  features  of  a  data 
base  manager  could  be  used.  This  would  provide  great  flexi¬ 
bility,  but  the  analyst  would  have  to  develop  a  program  for 
each  format.  Thus,  a  program  needs  to  be  developed  that  will 
assist  the  analyst  in  building  these  formats. 

Regarding  the  other  source  of  input  data,  observing  the 
system,  there  are  many  programs  and  collection  devices  that 


support  time  and  motion  studies  that  can  be  adapted  to  this 
function.  ;)acMillan  and  Ualker  (1985)  developed  such  a  pro¬ 
gram  that  provides  a  conceptual  framework  for  the  input  data 
collection  function  of  this  support  system.  The  next  chapter 
will  review  this  concept  and  outline  a  program  that  partially 
implements  this  specification. 


CHAPTER  6 

INPUT  DATA  COLLECTION  PROGRAM 

This  chapter  will  discuss  a  program,  written  in  Advanced 
BASIC,  which  is  conceptually  based  on  a  program  developed  by 
MacMillan  and  Walker  (1985),  but  enhanced  and  tailored  to 
meet  the  needs  of  data  collection  in  a  simulation  study.  The 
first  section  briefly  outlines  the  concept  of  MacMillan's  and 
Walker's  program.  The  second  section  provides  a  more  defin¬ 
itive  specification  on  which  this  program  was  built.  The 
third  section  discusses  the  operation  of  the  program  and  the 
last  section  will  provide  a  simple  example  to  demonstrate  its 
operation . 

Concept 


\ 

)  Basically,  a  data  collection  device  should  be  based  on 

t 

the  concept  that  the  analyst's  primary  function  is  to 
observe.  Data  entry  should  be  done  in  such  a  way  as  to  min¬ 
imize  the  time  the  analyst  spends  entering  data,  as  this 
distracts  from  this  primary  task  of  observing. 

MacMillan  and  Walker  developed  a  program,  written  in 
BASIC,  for  use  on  a  Radio  Shack  TRS-80  Model  100,  and  is 
recommended  for  a  starting  point.  By  using  the  computer 
clock,  the  time  an  event  occurs  can  be  logged.  They  have 
even  developed  a  routine  to  access  the  computer  timing 
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crystal  for  greater  accuracy.  When  an  event  occurs  the  oper¬ 
ator  hits  enter  and  the  time  is  logged.  The  operator  is 
then  prompted  for  an  event  number.  This  is,  in  turn,  entered 
and  logged.  The  operator  must  keep  track  of  event  or 
activity  numbers  and  the  logging  of  time  and  event  identi¬ 
fiers  requires  multiple  keystrokes.  Despite  these  drawbacks, 
it  does  offer  a  good  starting  point. 

Program  Specification 

Because  the  system  specification  developed  earlier  is 
rather  general  and  conceptual  in  nature,  this  section  will 
list  some  more  definitive  specifications. 

1.  The  program  should  be  menu  driven  and/or  the  user 
asked  to  respond  to  specific  questions;  i.e.  easy  to  use. 

2.  Data  entry  should  be  limited  to  a  single  keystroke 
to  the  maximum  extent  possible.  All  information  which  de¬ 
scribes  the  specific  event  or  activity  should  be  entered  prio 
to  beginning  data  collection.  This  is  so  the  analyst  can 
maximize  the  time  spent  observing,  and  thus  maximize  the 
number  of  events/activities  he/she  can  track. 

3.  The  computer  display  should  define  or  display  data 
to  be  collected  and  aid  in  tracking  the  collection  process. 
Put  another  way,  the  display  should  somehow  define  what 
activities  to  observe,  how  to  enter  data  for  this  activity, 
and  what  data  has  been  entered. 

4 .  All  data  file  operations  should  be  invisible  to  the 
user.  The  computer  should  manage  the  files,  not  the  user. 

5.  Data  files  should  be  identified  by  project, 


scenario,  study  number  and  activity  number.  The  project 
number  is  a  name  or  number  which  ties  the  data  to  a  particu¬ 
lar  simulation  project.  A  scenario  defines  a  specific  set  of 
activities  or  events.  A  study  number  defines  one  set  of 
homogeneous  data  collected  for  a  particular  scenario.  For 
example,  if  data  are  collected  on  a  particular  activity  over 
a  period  of  several  days,  each  days  data  would  be  associated 
with  a  particular  study  number  and  kept  in  a  separate  file. 
This  is  so  the  data  is  not  merged  until  it  can  be  statistic¬ 
ally  analyzed  to  determine  if  it  is  homogeneous. 

6.  The  program  should  also  collect  data  and  calculate 
statistics  that  supports  model  validation.  While  this  is 
more  a  function  of  properly  defining  the  proper  data  require¬ 
ments  (a  function  of  the  primary  support  system),  the 
collection  program  can  help  by  keeping  track  of  queue  size. 


etc . 


7.  Data  generated  in  this  program  will  be  filed  under 


the  ±INPUT  directory. 


Program  Development  and  Operation 


The  program  is  predicated  on  the  concept  that  the  model¬ 
ing  process  accomplished  by  the  primary  support  system  will 
determine  what  inputs  are  required  to  run  and  validate  the 
simulation  program.  What  the  support-support  system  will  do 
is  help  the  analyst  to  plan  how  the  data  will  be  collected 
and  a  means  to  collect  it  (see  Figure  11  for  general  logic 
diagram).  The  first  step  is  to  develop  a  plan. 


lnput/vaiidation 
Collection 
Reouirem e  n  t  s 


Develop 

Collection 


Verify 
„  Plan  . 


JM  o  d  i  f  y 

1  Plan 


Good 


Collect 

Data 


Figure  11.  General  Program  Logic 


Developing  the  Proiect  Plan 


The  plan  is  developed  by  building  she  required  collec¬ 
tion  scenarios.  The  scenarios,  as  defined  above,  are  the 
activities/events  an  analyst  will  observe  from  one  location. 
How  many  activities  one  analyst  can  observe  and  collect  data 
on  from  one  location  depends  on  the  physical  layout  of  the 


system,  the  complexity  of  the  a< 
skill  of  the  observer/collector 


'events ,  and  the 


This  program  allows  the  analyst  to  collect  data  for  six 
distinct  activities.  If  there  are  similar  activities  occur- 
ing  at  the  same  time  (termed  parallel  activities  in  this 
program)  the  program  will  collect  data  on  up  to  3  parallel 
activities  for  each  distinct  activity.  Thus,  one  scenario 
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may  actually  collect  data  on  up  to  18  activities/events. 

The  collection  plan  is  defined  by  a  simple  schematic 
composed  of  3  types  of  activities:  an  arrival  or  departure 
even  (circle);  a  delay  or  queue  event  (a  D  symbol);  and  an 
action  or  service  event  (a  square)  (Figure  12).  While  these 
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Figure  12.  Activity/Event  Symbols 


symbols  are  geared  to  queueing  systems,  the  action  or  service 
activity  can  represent  any  type  of  event  or  action;  i.e.,  the 
time  it  takes  to  service  a  bank  customer,  or  the  time  it 
takes  to  move  a  part  from  A  to  B,  or  the  time  it  takes  to 
perform  a  drilling  operation,  etc.  [Caveat:  This  program  is 
only  seen  as  a  starting  point.  The  number  or  symbols  and 
their  layout/display  can  be  changed  and  expanded  in  future 
program  enhancements.  The  present  layout  was  chosen  to 
maximize  the  amount  of  data  displayed  on  the  schematic  using 
normal  text  entry] 


To  build  this  plan,  you  start  the  program  and  at  the 
main  menu  (Figure  13)  select  option  1,  Develop  Collection 
Diagram.  The  result  is  an  input  format  (Figure  14).  An 


MAIN  MENU 

1.  DEVELOP  COLLECTION  DIAGRAM 

2.  MODIFY  COLLECTION  DIAGRAM 

3.  COLLECT  DATA 

4.  DATA  FILE  MAINTENANCE 

5.  EXIT  PROGRAM 


ENTER  SELECTION:?  [ 


Figure  13.  Main  Menu 

explanation  of  the  inputs  follows: 

A.  Project  NO/Ident  (8  characters)  -  Used  to  uniquely 
identify  the  project.  Can  be  either  letters  or 
numbers . 

B.  Collection  Scenario  NO  (2  characters)  -  Used  to 
identify  the  scenario.  Can  be  either  letters  or 
numbers . 

C.  NO  of  Activities  -  Used  to  identify  the  number  of 
collection  activities  for  the  particular  scenario. 
The  current  program  limits  the  maximum  number  of 
activities  to  6. 

For  each  activity  the  program  requests  the  following: 

D.  Type  of  Activity  (Select  From  Menu)  -  The  menu  is 
located  above  the  input  format  (Figure  14).  Can 
enter  1  of  3  type  of  activities  as  discussed  above. 

E.  Parallel  ACT(Y/N)  -  As  discussed  above,  if  activi¬ 
ties  of  the  same  type  as  that  defined  in  D  are  goin 


muimnuim 


58 


to  be  observed,  you  answer  Y.  This  allows  you  to 
increase  the  number  of  activities  you  can  observe 
and  collect  data  on.  If  the  answer  is  yes,  enter  Y. 
The  cursor  will  go  to  F.  If  you  enter  N  the  cursor 
by-passes  F  and  goes  to  G. 

F.  NO  -  The  number  of  parallel  activities  associated 
with  the  current  activity. 

G.  Description  of  Activity  (66  characters)  -  Allows  the 
user  to  enter  a  description  of  the  acti vity/event . 
Should  specify  enough  detail  to  sufficiently  define 
the  required  data. 

H.  Short  Description  to  be  used  to  label  schematic  (one 
or  two  words,  eight  characters  each)  -  On  the  col¬ 
lection  plan  schematic  each  activity  diagram  is 
labeled  with  these  words.  User  should  use  key  words 
to  help  in  identifying  the  collection  node.  If 
there  are  parallel  activities,  a  suggestion  is  to 

enter  1  of  _  (like  report  page  numbers)  so  you  can 

identify  which  activity  is  being  displayed. 

The  program  will  cycle  through  D-H  for  each  activity.  For 
parallel  activities,  the  program  will  cycle  G-H  for  each  par¬ 
allel  activity /event .  Thus  each  data  collection  point  is 
individually  defined  and  described. 

When  the  last  activity  information  is  entered  the  pro¬ 
gram  will  display  a  schematic  which  the  analyst  will  use  to 
collect  the  data  (Figure  15).  The  program  asks  the  user  if 
he/she  wants  to  make  any  changes  (not  shown  -  currently 
limited  to  a  change.  Add  a  symbol  and  delete  a  symbol  still 
have  to  be  added  to  the  program). 

After  all  changes  are  made  the  program  saves  this  infor¬ 
mation  to  a  file.  The  program  automatically  develops  a  file 
name  (Figure  16).  The  default  disk  drive  for  all  data  files 
is  always  drive  B.  The  program  then  returns  to  the  main 
menu . 

At  the  main  menu  the  user  can  develop  another  collection 
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B:  INPUT  P  R 
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First  Four  Scenario 

Characters  Number 

Of  Project 
Name 

*  Directory  path  not  included  in  current  program 
**  Simulation  Definition  File 

Figure  16.  Collection  File  Name 

scenario,  modify  an  existing  one,  or  retrieve  a  scenario  to 
collect  data.  [Option  4,  File  Maintenance  is  not  completed] 

Collecting  Data 

To  collect  data,  option  3  is  selected.  The  program  then 
prompts  the  user  for  a  project  name,  scenario  number,  and  a 
study  number  (previously  defined).  The  scenario  collection 
plan  is  retrieved  from  the  data  disk.  The  program  first 
displays  a  summary  of  the  file  information  (Figure  17).  Then 
the  collection  plan  schematic  is  displayed  (Figure  15). 

When  the  plan  was  developed,  an  input  key  (function  key) 
was  automatically  assigned  and  is  displayed  with  the  schema¬ 
tic.  For  arrival /departure  nodes  you  collect  one  clock  time 
each  time  the  event  occurs.  This  can  be  used  to  calculate 
interarrival  times.  The  delay  and  activity  nodes  have  two 
collection  points;  an  enter  or  begin  time  and  a  leave  or  end 
time.  The  program  then  calculates  a  duration  for  the  event. 
[Caveat:  as  currently  written  the  duration  or  average  delay 

time  will  only  be  accurate  for  FIFO,  first-in-first-out, 
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queue  priority.  Also,  a  time  in  system  can  only  be  deter¬ 
mined  for  single-queue, single-server  systems  with  FIFO  prior¬ 
ity.  However,  the  collection  scenario  will  not  always  define 
the  entire  system.  The  program  was  designed  to  collect 
data  on  various  parts  of  a  system  and  tne  order  in  which  the 
nodes  appear  should  reflect  the  order  in  which  events  are  to 
be  observed,  not  the  order  in  which  entities  flow  through  a 
system.  This  does  limit  some  of  the  validation  data  and 
needs  to  be  corrected  in  future  research.]  Also  calculated 
and  archived  are  maximum  number  in  queue  and  average  number 
in  queue. 

To  enter  data  for  a  particular  event  the  appropriate 
function  key  is  pressed.  The  program  calculates  the  time, 
places  the  time  data  into  an  array,  calculates  the  number 
in  queue  or  in  a  service  activity,  and  updates  the  display. 

If  there  are  parallel  activities,  the  computer  prompts  the 
user  for  the  appropriate  parallel  activity  number.  This 
number  is  entered  by  pressing  on  of  the  numeral  keys.  The 
enter  key  does  not  have  to  be  pressed  for  data  entry.  Thus, 
the  maximum  number  of  key  inputs  is  two.  The  user  does  not 
have  to  enter  any  other  identifying  data.  This  was  already 
done  in  the  scenario  development  phase. 

The  other  information  displayed  on  the  screen  during 
data  collection  is  the  name  of  the  project,  the  scenario 
number,  and  study  number.  When  the  collection  routine  is 
first  called,  a  start  time  is  calculated  and  displayed.  The 
same  thing  occurs  when  data  collection  is  terminated.  The 
amount  of  memory  remaining  is  also  displayed.  If  the  machine 


has  more  than  256K  of  RAM,  memory  shouldn't  be  a  major  prob¬ 
lem.  The  machine  used  to  develop  and  run  this  program  only 
had  256K  which  limits  the  number  of  collection  entries  per 
activity  to  between  50  and  75,  and  the  number  of  parallel 
activities  to  3. 

To  terminated  data  collection,  the  Ctr-FlO  keys  are 
j  pressed  simultaneously.  When  this  is  done,  the  data  is  auto¬ 

matically  stored  to  files  on  the  data  disk.  Each  activity 
has  it's  own  file.  Data  Files  are  formatted  as  shown  in 
Figure  19.  Data  stored  includes  the  activity  identifying 
data,  the  raw  time  data,  the  number  of  data  entries,  and 
for  an  arrival/departure  event;  interarrival  times,  maximum 
interarrival  time  and  the  average  interarrival  time.  For  the 
delay/queue  activity,  the  raw  enter/leave  times  are  entered 
along  with  elapsed  time,  maximum  number  in  queue,  average 
number  in  queue,  maximum  delay  time,  and  average  delay  time. 

I  For  service/action  activities,  the  raw  enter/leave  times  are 

entered  along  with  elapsed  serviced  times,  maximum  service 
times  and  average  service  times. 

A  file  identifier  is  calculated  as  shown  in  Figure  19. 

Programming  Notes 

It's  necessary  to  point  out  that  Advanced  BASIC  is  re¬ 
quired  to  run  this  program  because  of  the  schematic  drawings. 
A  complete  program  list  is  a  Appendix  C  and  includes  a  list¬ 
ing  of  the  program  variables  and  subroutines.  The  program 
makes  extensive  use  of  subroutines  and  should  hopefully  be 


64 


ARRIVAL/DEPARTURE 

ACTIVITY 

_ A _ 

Project  Name , Scenario  No,  Program  Counter 
Activity  Type , Parallel  Activity  No, Program  Counter 
Long  Activity  Description 

Short  Activity  Description  1, Short  Activity  Description  2 
Study  No , Date , Star t  Time , Ter minate  Time 
Number  of  Observations  in  This  File 

Number  of  Entities  or  Actions  Completed  in  this  Activity, 0 
Observation  Number,  Event  Time,  Time  Since  Last  Event  (IAT) 

Average  Interarrival  Time,  Maximum  Interarrival  Time 


DELAY  OR  SERVICE 
ACTIVITY 

_ A _ 

I 

i 

I 

|  First  7  entries  the  same  as  Arrival /Departure  Event 

« 

j  Entry  8 

I  Observation  Number, Enter  Time,  Leave  Time,  Elapse  Time 

i 

i 

Average  Elapse  Time(Service  Time),  Maximum  Elapse  Time, 
Average  Queue  Length  (For  Delay  Activities) 


B:  INPUT 


.  SCF 


First  2  STUDY 

CHARACTERS  NO 

Of  PROJECT 
NAME 

SCENARIO 

NO. 


ACTIVITY 

IDENTIFIER 

NUMBER 


*  Directory  Path  not  included  in  current  program. 
**  Simulation  Collection  File 


Figure  19.  Collection  File  Name 


easy  to  follow.  This  section  will  briefly  discuss  a  few  of 
program  techniques. 

Accessing  the  Computer  Clock.  The  program  uses  the  same  tech¬ 
nique  as  MacMillan  and  Walker  (1985).  When  the  clock  time  is 
required,  the  time  is  entered  into  the  character  variable  T$ 
using  the  TIME$  function  (line  number  5400).  The  character 
variable  is  then  converted  to  a  numerical  value  using  the 
VAL  function  (line  number  5755).  The  TIMES  function  is  in 
the  format  hr:min:sec.  The  numerical  value  is  converted  to 
minutes  by  multiplying  the  hours  value  by  60,  adding  it  to 
the  minutes  value,  and  then  adding  this  to  the  seconds  value 
divided  by  60.  (for  greater  accuracy  see  MacMillan  and 

TT11 

h  a  l  n  c  i  j.  >  ^  D  )  ■ 

Programming  the  Function  Keys.  The  function  keys  are  pro¬ 
grammed  using  the  INKEY$  function  (subroutine  5300)  and  the 
extended  ASCII  codes.  Because  a  function  key  returns  a  two 


character  set  from  the  keyboard,  the  length  of  the  key  return 
is  checked  (lines  5370  and  5380).  The  INKEY$  value  (FKEY$) 
is  truncated  and  the  ASCII  value  calculated  using  the  ASC 
value.  This  value  determines  which  F-key  was  pressed;  F1-F10, 
Shift  F1-F10,  Ctl  F1-F10,  or  Alt  F1-F10.  Once  the  program 
identifies  which  F-key  was  pressed  it  compares  it  to  the 
input  F-key  assigned  to  each  activity.  (For  more  information 
see  the  BASIC  User's  Manual) 

Schematic  Symbols.  The  symbols  are  drawn  using  simple  LINE 
and  Circle  functions  (subroutines  1000,1200,  and  1400).  The 
position  of  the  symbol  is  determined  by  the  activity  position 
number  (1,2, 3, 4, 5,  or  6)  and  coordinates  extracted  from 
subroutine  2200. 


Example 


To  demonstrate  how  a  collection  plan  is  developed  and 
data  collected,  this  section  will  examine  a  simple  example. 

The  example  consists  of  a  model  to  simulate  a  small  bank 
operation.  The  bank  has  4  tellers  with  a  single  queue.  Cus¬ 
tomers  enter  and  exit  through  a  single  door.  The  bank  layout 
is  shown  in  Figure  20. 


\ 


- Queue  ~  ' 


J 


I  1 
I  2 

I  3 

I  ^ 


Tellers 


Figure  20.  Bank  Layout 


6 


To  run  the  simulation,  the  interarrival  times  of  the 
customers  and  the  mean  service  time  for  each  teller  are 
required.  To  help  validate  the  model,  the  average  length 
of  the  queue  and  the  average  time  spent  in  the  queue  are 


required . 


To  build  the  scenario,  option  1  is  selected  at  the  main 
menu  and  the  data  plan  input  (see  Figures  22-27).  The  sche¬ 
matic  is  then  displayed  and  checked  for  accuracy  (Figure  28) 
The  program  asks  if  there  are  any  changes.  There  aren't,  so 
N  is  entered  and  the  program  saves  this  information  to  file 
PRBANK01 . SDF . 

To  collect  data,  option  3  is  entered  at  the  main  menu 
and  the  program  asks  for  a  Project  NO/IDENT.  The  name  Bank 
is  entered.  It  then  asks  for  a  scenario  number.  Number  1 
is  entered.  Finally  it  asks  for  a  study  number.  Since  this 
is  the  first  data  collection  study  using  scenario  1,  the 
number  1  is  entered  (see  Figure  29). 

ENTER  PROJECT  NO/IDENT:?  BANK 
ENTER  SCENARIO  NO:?  1 
ENTER  STUDY  #:?  1 

Figure  29.  Collection  Plan  Retrieval  ID 

The  information  defining  the  scenario  is  retrieved  and 
the  plan  summary  is  displayed  (Figure  30).  The  collection 
schematic  is  then  displayed,  Figure  28,  and  the  collection 
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Figure  24.  Input  Display  For  Activity  3,  Parallel  Activity  2,  Bank  Example  (Teller  2  Service) 
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Input  Display  For  Activity  3,  Parallel  Activity  4.  Bank  Example  (Teller  4  Service) 


Figure  27.  Input  Display  For  Activity  4,  Bank  Example  (Customer  Departs  Bank) 
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process  begun.  Figure  31  shows  a  screen  display  during  the 
collection  process. 

For  this  example  the  time  was  compressed  and  collection 
terminated  after  12  arrivals.  Ctl-FlO  was  pressed  and  the 
data  was  stored  to  files  BAO 1 0 1 0 1 . SCF-BAO 1 0 1 07 . SCF  .  The  file 
contents  are  shown  in  Figures  32-38  (refer  to  Figure  18  for 
format. 

This  is  just  a  short  example,  but  it  does  show  the  type 
of  raw  data  that  can  be  sent  to  the  primary  support  system 
for  analysis.  It  also  highlights  again  the  data  that  cannot 
currently  be  collected  with  this  program,  and  some  problems 
to  watch  for  in  the  output  data. 

For  example,  because  there  are  parallel  service  activi¬ 
ties,  you  cannot  determine  the  average  length  of  time  a 
customer  spends  in  the  bank,  or  even  the  average  number  of 
customers  in  the  bank  at  any  one  time.  You  can  approximate 
the  length  of  time  a  customer  spends  in  the  bank  by  adding 
the  average  waiting  time  and  average  service  time  together. 
This  is  not  very  accurate,  though,  and  this  capability  needs 
to  be  added. 

Also,  Figure  34,  the  data  for  teller  1,  shows  a  negative 
average  service  time.  This  occurred  because  collection  ter¬ 
minated  with  a  customer  still  at  teller  number  1.  This  will 
often  happen,  so  the  data  needs  to  be  reviewed  prior  to 
analysis  and  this  type  of  data  removed. 

Originally,  the  plan  was  to  incorporate  some  statistical 
analysis  software  directly  into  the  program.  Instead,  a 
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Type  "exit"  to  return  to  the  application 
B : \  E > T V PE  BA 0 1 0 1 Oi . S C F 
"BANK" , "01 " ,4 
1,1,1 

"CUSTOMER  ENTERS  BANK /PROCEEDS  TO  QUEUE" 
"OUST " , "ARRIVES" 

"01" , " 03— £2— 1 987 " , "£8:43:06" , " £8:58:03" 

1 8 


1  £ ,  0 

I ,  1 368 .117, 5 . O 1 6784 

8 . 1 368 . 367 . .  85 

3 . 1 363 . 567 . .  1 9995 1 8 

4 , 1 368 . 583 , 1 . 678363L-08 

5 . 1 368 . 967 . .  3833008 

6 . 1 369 . 65 . .  6833496 
7, 1371 .083, 1 .43335 
8 , 1 378 . 35 , 1 . 866608 
9,1 378 .4,5. 004883E— <  >8 
10, 1 373 . 467 , 1 . 06665 

II, 1 374 .717,1. 85 
18, 1 377 . 05 , 8 . 333374 
1 . 073'  >8  t ,  8 . 333374 


Se  1  ec 


C1  ■ 


Figure  32.  Data  File  For  Activity  1,  Customer 
Arrivals  (Bank  Example) 


Type  "exit"  to  retur  n  t  the  Appl  1  cat*  on  Selector. 

B:\  B;  TYRE  BA010108.SCF 
"BANK" , "01  "  ,4 
8 ,1,8 

"CUSTOMER  WAITS  FOR  TELLER  TO  BE  FREE/SINGLE  QUEUE 
"COST" , "WAITS" 

"01" , "03-88-1987" , "88:43:06" , "88:58:03" 

8 

8,1 

i  , 1 369 , 1 370 . 45 , j  . 44  995 1 

8 . 1  36 9 . 693 , 1  3  ?<.:!. ,  1  1 7  ,  c’ .  43335 

3 . 1  37 1.15,1  373 . 9  ,-j .  75 

4 . 1378. 483 . 1  374 . 1  o3  ,  1  .  7'  >0073 
5 , 1 378 . 5 , 1 375 . 083 , 8  -  583374 

6 , 1 373 .433,1 375 . 483 -  8 
7 , 1 37h -  867 , 1 376 .183,1 . 3 1 665 
8 , 1 377 .1,1 377 . 583 , . 4833985 


Figure  33.  Data  File  For  Activity  2,  Customer 
Waits  (Bank  Example) 


.  I  ig|  •  •« « -||4 l '•) * i .  i 


T  ype  "  e  •:  it"  to  return  to  the  Application  Se lento 
B  :  \  B > T  YPE  BAG 1 0 1 03 . SCF 
"BANK" , "01 " ,4 
3  %  1  ,  3 

"CUSTOMER  SERVICED  BY  TELLER/ 1  OF  4  TELLERS" 
"TELLER l","!  OF  4" 

"01" , "03— EE— 1937" , "EE  :43  s 06", "EE: 58: 03" 


1,1  363  .  S  ,  1  370 .  3  ,  E  .  1  (J009S 
S , 1 370 .5,1 374 . 933 , 4 . 43335 
3 , 1 375 .133,1 377 . 333 , E . E00073 
4 , 1 377 . 65 , O . - 1 377 . 65 
-E73 . 7833 , 4 .43335 , O 

Figure  34.  Data  File  For  Activity  3,  Teller  1 
(Bank  Example) 


i  ype  "exit"  to  return  to  the  Appl  ic.=>t  ion  Selector 
B  :  \  B  > T  YF'E  BAG 1  0 104.  SCF 
"BANK" , "01 " ,4 
3  ,  E  ,  3 

"CUSTOMER  RECEIVES  SERVICE  BY  TELLER  £/  E  OF  4" 
"TELLERS" , ”S  OF  4" 

"01", " 03— ES— 1 987 " , " EE : 43 : 06 " , " EE : 58 : 03 " 

E 

E ,  O 

1 , 1 368 . 45 , 1 374 . 0 1 7 , 5 . 566773 
P. ,  1  374 . 367 ,1377. 367 , 3 
E . 35559 1,5. 566773 , O 

Figure  35.  Data  File  For  Activity  3,  Teller  2 
(Bank  Example) 


Type  "e* it"  to  return  to  the  App 1 icat i on  Selector 
B:\  B > TYPE  BAG 1 O 1 05 . SCF 
"BANK " , "01 " , 4 
3 , 3 , 3 

"CUSTOMER  RECEIVES  SERVICE  FROM  TELLER  3  /  3  OF  4 
"TELLERS", "3  OF  4" 

"  0 1  "  ,  " 03 -EE-  1  987 11  ,  " EE  :  43  :  06  "  ,  "  EE  :  58  :  03  " 


1,1 368 . 667 , 1 37 1 . 95 , 3 . SB3d£5 
S ,  1  37E  .  E  17,1  376 .1,3. 8 £1330 1 
3 , 1 376 . E 1 7 . ; 377 . 383 ,1.1 666E6 
2 . 0833 1  3 , 3 . 883*  «*.»1  .  >.  - 

Figure  36.  Data  File  For  Activity  3,  Teller  3 
(Bank  Example) 


yy.y.v.y.y^^^ 


nj  r 


I ype  exit"  to  return  to  the  Application 
B:\  B.-TYPE  B  A  0 1 0 1 0  6 .  S  C  F 
"BANK" , "01 " ,4 
3,4,3 


" CUSTOMER  RECE I VES 
"  TELLER*'*  "  ,  "  4  OF  4" 
"01"  ,  "03-22-198?"  , 


SERVICE  FROM  TELLER  4 
22:43: 06 " , " 22 : 53 : 03  " 


3 


Se  1  u  t 


/  4  OF 


3 , 0 

1  ,  1 368 . 733 , 1 373 .7,4. 966675 
, 1 373 . 933 , 1 375 .3,1. 366699 

, 1 375 .517,1 377 .417,1. 899902 

2  .  0533 19,4. 966675. , . . 


Figure  37.  Data  File  For  Activity  3,  Teller  4 
(Bank  Example) 


Type  "exit"  to  return  to  the  Application  Select 
B:\  B; TYPE  BA010107.SCF 
"BANK" , "01 " ,4 

I, 1,4 

"CUSTOMER  DEPARTS  BANF " 

"OUST" , "DEPARTS" 

"01 " , "03-22-1987" , "22:43:06" , "22:53:03" 

1  1 

I I ,  0 

1  j  1  3  7  O  m  3  6  7  %  f  *+ 

2 , 1 372 .017,1. 650024 
3 , 1 373 . 783 , 1 . 766602 

4 . 1  374  .  .1  33 ,  .  3499756 

5 . 1 375 . .  8666992 

6 . 1 375 .35. .  3499756 

7 . 1 376 . 1 33 . .  7833252 
8 , 1377. 467 , 1 . 333374 

9 , 1 377 . 483 , 1 . 660 1 56E— 08 
1 O , 1 377 .5,1 . 672363E . 02 

11.1  3  .-'7 .51 7 , 1 . 672 363 E.  — '  >2 
1 .201396, 1 .766^08 


Figure  58.  Data  File  For  Activity  4,  Customer 
Departs  (Bank  Example) 


simple  statistical  package,  such  as  Statistical  Analysis 
from  HE  Microsoftware  is  recommended.  The  input  routines 
can  be  adjusted  to  read  in  data  from  these  data  files. 

The  program  does  organize  and  simplify  the  collection 
process.  It's  only  a  starting  point,  and  many  improvements 
need  to  be  made. 


CHAPTER  7 


SUGGESTIONS  FOR  FUTURE  RESEARCH 


The  research  has  shown  that  there  has  been  a  need  for 
a  more  organized  and  structured  approach  for  carrying  out 
simulation  projects.  Furthermore,  integrated  simulation  sup¬ 
port  systems,  such  as  TESS,  or  concepts  implied  in  a  model 
management  system,  have  sought  to  implement  methodologies  to 
answer  this  need.  However,  these  systems  still  require 
quality  data/information  to  operate  and  do  not  support  the 

\ 

‘  process  of  collecting  the  data.  This  thesis  has,  therefore 

proposed  a  system  to  support  the  da t a / i n f or ma t i on  needs  of 
these  simulation  support  environments.  The  objective  has 
been  to  develop  a  system  concept  for  supporting  the  entire 
simulation  process. 

A  system  specification  has  been  developed  which  seeks  to 
achieve  four  general  requirements  in  support  of  six  f unction- 
I  al  areas.  These  requirements  call  for  the  proposed  support 

'  system  to  help  in: 

|  1.  organizing  and  guiding  the  collection  effort; 

I  2.  organizing  and  archiving  the  data; 

i 


3.  displaying  the  data  for  review,  analysis,  update  and 
validation;  and 

4.  producing  required  reports. 

The  six  data  collection  functions  include: 


I 
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1.  problem  formulation 

2.  system  description 


3.  model  input  data  collection 

4.  project  management 

5.  cost/benefit  analysis 

6.  reports  generation 

To  implement  this  specification  this  study  proposed 
using  a  portable  microcomputer  as  a  collection  workstation. 
With  the  ability  to  operate  any  of  the  software  a  regular  PC 
can  run,  and  its  natural  ability  to  archive  data,  it  can 
provide  the  needed  tools  to  support  the  collection  effort. 

By  developing  standardized  application  programs  for  generic 
software,  such  as  spreadsheets,  data  base  managers,  word 
processors,  graphics  software,  and/or  a  common  programming 
language  such  as  BASIC,  the  analyst  can  adjust  them  to  his/ 
her  own  desires  and  to  the  particular  needs  of  the  project. 

In  order  to  demonstrate  how  this  concept  could  be  imple¬ 
mented  a  BASICA  program  was  developed  to  support  the  model 
input  data  collection  function.  Despite  this  effort,  the 
system  is  still  at  a  highly  conceptual  stage  and  a  great  deal 
of  work  remains  to  be  done.  The  remainder  of  the  chapter 
will  therefore  outline  some  suggestions  for  future  research, 
beginning  with  a  summary  of  the  work  necessary  to  individual¬ 
ly  implement  the  six  system  functions  and  concluding  with  two 
general  areas  of  research  suggested  by  this  study. 


* « •  »*  •  ' *  o 
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System  Functions 


Problem  Formulation 


As  suggested,  the  methodology  proposed  by  Balci  and 
Nance  (1985)  appears  to  represent  a  very  good  starting  point. 
Utilizing  a  programmable  data  base  manager  should  provide  the 
flexibility  and  logic  necessary  to  guide  the  analyst  through 
the  process.  This  will  require  additional  work  in  the  fol¬ 
lowing  areas : 

1.  Development  of  standard  q ue s t i on s  /  i n f or ma t i on  needs 
formats  and  logic. 

2.  Development  of  data  files  to  archive  this  data. 

3.  Identification  and  formats  those  standard  files  that 
will  be  used  by  the  programs  of  the  other  system 
functions. 


Input  Data  Collection 


The  program  developed  to  support  input  data  collection 
meets  most  of  the  specification.  It's  easy  to  use.  File 
operation  is  invisible  to  the  user,  and  a  minimum  number  of 
keystrokes  are  required  to  enter  data.  The  user  only  has  to 
respond  to  input  prompts  to  define  a  collection  plan  and  a 
schematic  collection  format  is  produced  automatically. 

To  fully  meet  specifications,  however,  it  still  needs 
to  be  coupled  to  a  statistical  software  package  so  that  some 
preliminary  analysis  can  be  conducted.  As  mentioned  already, 
the  HE  Statistical  Analysis  package  would  provide  a  good 
starting  point.  It  is  written  in  BASIC,  so  all  that  is 
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required  is  a  subroutine  to  access  and  read  the  data  from 
the  files.  An  even  simpler  step  in  this  direction,  is  a  sub¬ 
routine  to  summarize  the  statistics  already  calculated  by  the 
program . 

Additionally,  error  trapping  routines  have  to  be  deve¬ 
loped  for  the  data  entry  event.  This  will  insure  that  an 
obviously  bad  key  selection  is  not  accepted  until  verified. 

If  some  bad  data  is  collected,  a  routine  is  needed  to 
cleanse  the  data  prior  to  saving  it  to  disk  storage. 

Also,  as  relates  to  specifications,  the  capability  to 
capture  more  data  for  validation  purposes  is  required.  The 
ability  to  track  entities  through  each  collection  activity 
will  solve  this  problem,  for  the  most  part. 

Finally,  as  it  relates  to  input  data  collection,  a  pro¬ 
gram  is  needed  to  support  data  collection  from  documented 
sources.  In  some  projects  documents  may  represent  the  major 
source  of  data . 


System  Description 


Here,  future  research  should  focus  on  developing  a  col¬ 
lection  of  software  tools  to  help  the  analyst  develop  a 
static  representations  of  the  system.  The  various  methods 
mentioned  earlier,  process  charts,  activity  charts,  flow 
diagrams,  etc.,  are  possible  starting  points.  The  flexibili¬ 
ty  of  a  small  CAD  package  could  represent  one  possibility. 
Also,  the  data  collection  program  discussed  in  the  previous 
chapter  could  provide  a  means  to  collect  data  for  an  activity 
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chart.  The  program  that  utilizes  this  data  could  then  be 
developed  to  schematically  display  an  activity  chart. 


Project  Management  &  Cost/Benefit  Analysis 


Primary  job  here  is  to  continue  the  task  analysis  in 
order  to  develop  a  good  standard  project  schedule  that  can  be 
used  as  a  starting  point  to  estimate  and  manage  the  project. 

A  major  issue  is  how  the  resources  and  cost  to  accomplish  a 
project  are  to  be  estimated.  Software  development  cost  has 
always  been  difficult  to  estimate.  To  complicate  this 
process,  however,  will  be  the  use  of  the  support  systems. 

How  will  this  affect  the  cost  of  the  project.  While  they 
should  hopefully  make  the  process  more  efficient,  it  will 
result  in  additional  computer  time.  So  this  aspect  is  cur¬ 
rently  an  unknown  and  requires  additional  research. 


Reports  Generation 


Here  again  standard  formats  have  to  be  defined  both  for 
update  reports  and  also  project  proposal  formats. 


General  System  Requirement 


A  key  aspect  is  the  design  of  the  underlying  data  base 
structure.  The  concept  calls  for  data  that  pertains  to  more 
than  one  functional  area  to  be  accessible  to  each  of  the 
applicable  programs.  This  requires  the  identification  and 
design  of  standard  universal  files.  For  example,  for  the 
project  manager  to  track  resources  expended,  each  system 


APPENDIX  A 


PROGRAM  LISTING 


'  1  ‘y|  ‘«'V 


ww  vw  MwiwRMAk  ^ -j*  -vm  -u*  r\jt  rjiTVW  rjirjtAa»njrru^r\^  rw»n^  ^  r j*  nr .  w.  r?nm rw\i  w\j  w 


Subroutine 

100 

200 

300 

500 

700 

1000 

1200 

1400 

1600 

1800 

2000 

2200 

2400 

2600 

2800 

3100 

3300 

3600 

3900 

5300 

5500 

5700 

5820 

6000 

6300 

6500 

9000 

9500 

9700 

10000 

11000 

50000 

51000 


TABLE  8 


PROGRAM  SUBROUTINES 


Description 

Develop  Collection  Schematic 
Modify  Collection  Schematic 
Collect  Data 
Display  Main  Menu 
Draw  Schematic 

Draw  Activity  Diagram  (Square) 
Draw  Arrival/Depart  Diagram 
(Circle) 

Draw  Delay  Diagram 
Label  Activity  Diagram 
Label  Arr i val /Depart  Diagram 
Label  Delay  Diagram 
Define  Diagram  Position 
Menu  -  Type  Activity 
Define  Collection  Schematic 
(input  format) 

Define  Collection  Schematic 
(Prompts  for  input) 

Clear  Input  Spaces 
Write  Schematic  Definition 
To  File 

Retrieve  Schematic  Definition 
From  File 

Summarize  Project  File 

(schematic  definition) 
Collect  Data 

Identify  Which  F-Key  was 
Pressed 

Enter  Data  into  Array 
Find  Parallel  Activity  No. 
Update  Display  -  Arrival /Depart 
Update  Display  -  Delay 
Update  Display  -  Service/Action 
Save  Collection  Data  to  File 
Save  To  File  (Type  1  data  - 
arrival/depart) 

Save  to  File  (Type  2&3  data- 
delay  and  service) 

Print  Diagram  Header 
Modify  Diagram 
Assign  F-Key  to  Activity 
Clear  Bottom  Half  of  Screen 


NCV2VJV 
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TABLE  9 


KEY  PROGRAM  VARIABLES 


Variable 


ACTIVITY POS(I) 


ACTIVITYTYPE(I) 

LONGACTDESCRIPT(I.J) 

SHORTACTDESCRIPT(N,I,K) 


F$(N, I) 

F(  N  ,  I  ) 
F1(M,I, J,K) 
LAST( I , J , K ) 
NOTHROUGH(I.K) 


NOIN(I.K) 


MAXCONT ( I , K ) 


SUMNOIN ( I , K ) 


ETAVG 


Description 


Activity  number  (1-6) 

Parallel  activity  number  (1-6) 

Collection  point  on  a  Delay  or 
service  activity 

1  =  enter/begin 

2  =  leave/end 

Observation  number 

Defines  symbol  position  on  the 
screen 

Defines  type  of  symbol 

Long  description  of  activity 

Short  activity  description  of 
activity 

Function  key  label  for  diagram 

ASCII  code  for  function  key 

Time  event  is  logged 

Number  of  observations 

Number  of  entities  through  an 
activity 

Number  of  entities  currently  in 
a  delay  activity 

Maximum  number  of  entities  in  a 
delay  activity 

Sum  of  the  number  of  entities 
a  delay  activity 

Average  elapse  time  -  delay  or 
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TABLE  9 


CONTINUED 


I 


ETMAX 

QLENAVG 

ET 

ETT 

SCENARIO$ 
PROJECTS 
STUDY  $ 
FIL$ 

PARACTNO(I) 


Maximum  elapse  time  -  delay  or 
service  activity 

Average  number  in  a  queue 

Elapse  time  (service  or  delay) 

Total  elapse  time 

Scenario  number 

Project  name 

Study  number 

File  name 

Number  of  parallel  activities 
for  activity  I 


5  CLS 

10  CLS : SCREEN  2 
20  DIM 

ACT  I  VI  TYPOS ( 6 >  . ACTIVITYTYPE<6>  , LONGACTDESCR I PT$ ( 6 , 6 )  , SHORT AC  T 
DESCRIPT (2,6,6),F$(2,10>,F(2,10>,F1<75,6,2,4)  , LAST<  6,2 .6  >  , NOT 
HROUGH (6,6  )  , NO  I N ( 6 , 6 )  , MAXCONT ( 6 , 6 )  , SUMNO I N ( 6 , 6 )  : I F  G= 1  THEN 
RETURN 

30  ON  ERROR  GOTO  60000 

40  GOSUB  500  ’DISPLAY  MAIN  MENU,  GET  SELECTION 

50  ON  IN  GOSUB  100,200,300,70,70 
60  GOTO  40 
70  SYSTEM 


’**■**#****♦******##******#********#*****♦«■****»**»#****»***** 
#•*•*#•***#*#**#■**  96  ’ 

97  ’ 

100  ’  SUBROUTINE  100  -  DEVELOP  COLLECTION  SCHEMATIC 

1  10  ’ 

120  ’ 

130  CLS : GOSUB  2400  ’PRINT  ACTIVITY  MENU 

135  GOSUB  2600  ’PRINT  INPUT  FORMAT 

140  GOSUB  2800  ’GET  INPUTS 

145  CLS : GOSUB  700  ’DRAW  DIAGRAM 

147  GOSUB  11000  ’SEE  IF  USER  WANTS  TO  MODIFY  DIAGRAM 

150  GOSUB  3300  ’SAVE  DIAGRAM  TO  FILE 

155  RETURN 

160  ’ 

165 

’*■**#■*-■*-*#  **************#******##*********«-********'***  ■»*#•■*•***# 
#.*****■*#•*■***■**  170  ’ 

175  ’ 

200  ’  SUBROUTINE  200  -  MODIFY  COLLECTION  DIAGRAM 

210  ’ 

220  ’ 

230  GOSUB  3600  IDENTIFY  WHICH  K I LE  AND  RETRIEVE 

INFO  235  GOSUB  10000  ’PRINT  HEADER 

240  GOSUB  700  ’DRAW  DIAGRAM 

245  GOSUB  11000  ’ASK  WHAT  IS  TO  BE  CHANGED 

250  GOSUB  3300  ’SAVE  TO  FILE 

255  RETURN 

260  ’ 

265 


SUBROUTINE  300  -  COLLECT  DATA 


320  GOSUB  3600 
325  GOSUB  10000 
330  GOSUB  700 
335  GOSUB  5300 


RETRIEVE  DIAGRAM  FROM  FILE 
'PRINT  HEADER  INFO 
'  DRAW  DIAGRAM 
’COLLECT  DATA 


I 

iwuw 


i 


*******  ***  ****  360  ’ 


IF  G= 
CLS 

LOCATE 

LOCATE 


SUBR0LT1NE  500  -  DISPLAY  MAIN  MENU 

1  THEN  CLEAR:G=1 :GOSUB  BO 

B , 3S : PR  I  NT  "DATA  COLLECTION" 

5 , 35 : PR I  NT  "MAIN  MENU" 


LOCATE  8 , BO : PR  I  NT  ' 

LOCATE  1 0 , 20 : PR  I  NT 
580  LOCATE  12,B0:PRINT  "3.  COLLECT  DATA" 

590  LOCATE  14,20:PRINT  "4.  DATA  FILE  MAINTENANCE  (not 
comp  1  eterj  )  "  600  LOCATE  16,B0:PRINT  "5.  EXIT  PROGRAM" 

620  LOCATE  22, 15: INPUT  "ENTER  SELECT  I  ON : " ; I N 
630  RETURN 
640  ’ 

650 

’  ************************************************************ 
******  -a-***-****  660  ’ 

670  ’ 

700  ’  SUBROUTINE  700  -  DRAW  SCHEMATIC 

710  ’ 

720  ’ 

730  FOR  I  =  1  TO  N 
740  J  ACT  I  V  I  T  YTYPE  (  I  ) 

750  ON  J  GOSUB  1800,2000,1600 
760  NEXT  I 
770  RETURN 
780  ’ 

785 

’************************************************************ 
**************  790  ’ 

795  ’ 

1000  ’  SUBROUTINE  1000  -  DRAW  ACTIVITY  DIAGRAM 

1010  ’ 

1 020  ’ 

1030  ’ KP=ACT I V I TYPOS ( I  ) : GOSUB  2200 
1040  LINE  ( X ,54)-( X+70, 128) , ,B 

1050  LINE  (X— 18,91)— (X, 91 ):LI NE  < X+70 , 9 1 > - < X+B8 , 9 1 ) 

1060  LINE  ( X+2,66)-< X-3,66) : L I NE  -(X-3,140) 

1070  LINE  ( X+68, 122)-( X+73, 152) :LINE  -  (X+73,140) 

1090  RETURN 
1 090  ’ 

1  1  00 

’************************************************************ 
************  j  j  i(i  ’ 

1  1=0  ' 


1.  DEVELOP  COLLECTION  DIAGRAM" 
"2.  MODIFY  COLLECTION  DIAGRAM" 
"3.  COLLECT  DATA" 

"4.  DATA  FILE  MAINTENANCE  (not 
1 6 , 20 : PR  I  NT  "5.  EXIT  PROGRAM" 
"ENTER  SELECTION: "f IN 


SUBROUTINE  700  -  DRAW  SCHEMATIC 


FOR  I  =  1  TO  N 
J  ACT  I  V  I  T  YTYPE  <  I  ) 

ON  J  GOSUB  1800,2000,1600 

NEXT  I 

RETURN 


i 


a 


1200  ’  SUBROUTINE  1  BOO  -  DRAW  ARR I VE / DEPART (CIRCLE  > 

DIAGRAM  1210  ’ 

1  220  ’k'P=ACTI  VI  TYPOS  (  I  )  :GOSUB  2200 
1230  CIRCLE  < X+35,91 > ,35, ,, ,24/25 

1240  LINE  < X-13,91  ) -( X ,91  )  :L INE  ( X  +  35 ,  1 26 ) - ( X+35 , 1 40 )  : L 1  ME 
( X+70.91 >-< X+88,91 )  1250  ’ GOSUB  1800 

1260  RETURN 
1270  ’ 

1290 

************  #  1290  ’ 

1  300  ’ 

1400  ’  SUBROUTINE  1400  -  DRAW  DELAY  DIAGRAM 

1410  ’ 

1420  ’ KP=ACT I  V I  TYPOS ( I  ) : GOSUB  2200 

1430  Pl=3. 141593:CIRCLE  < X +42 , 9 1 ) , 38 ,  , 3*P I /2 , P I /2 , 24 / 25  1 1 

LINE  ( X+42,54 >-< X ,54 ) sLINE  - ( X , 1 28 ) : L I NE  -(X+42,120)  1450 

LINE  (X+B,64)-(X-3,64) :LI NE  - ( X -3 , 1 40 ) : L I NE  (X+72,118)- 


1420  ’KP=ACTI VI  TYPOS < I  > sGQSUB  2200 

1430  Pl=3. 14 1593:CIRCLE  < X +42 , 9 1 ) , 38 , , 3*P I /2 , P I /2 , 24 / 25  1440 

LINE  ( X+42,54 )-( X ,54 ) :LINE  - ( X , 1 28 > s L I NE  -<X+42,120>  1450 

LINE  <X+2,64)-(X-3,64) : L I NE  - ( X -3 , 1 40 ) : L I NE  (X+72,118)- 
(  X  +  76 , 1  1  8  )  :  L  I  NE  -(  X+76, 140)  1460  LINE  (  X  ,  9  1  )  -  (  X  -  1  8 , 9  1  >  :  L  I  NE 

<  X  +79 ,91 )-( X+88,91  ) 

1470  RETURN 
1480  ’ 

1490 


SUBROUTINE  1300  -  LABEL  ACT  I  VI TY ( SQUARE )  DIAGRAM 


*************  1500  ’ 

1510  ’ 

1600  ’  SUBROUTINE  1300  -  LABEL  ACT  I VI TY ( SQUARE )  DIAGF 

1610  ’ 

1620  KP=ACT I  V I T YPOS <  I  ) :GOSUB  2200 

1630  LOCATE  5 , NP 1 : PR  I  NT  SHORT AC TDE SCR  I PT$  <  1  , 1  , 1  > 

1640  LOCATE  6,NP1:PRINT  SHORT AC TDE SCR  I PT$ ( 2 , I  ,  1  ) 

1650  LOCATE  8 , NP 1 : PR I  NT  "START" 

1660  ’ LOCATF  9,NP1:PRINT  TIME* 

1670  LOCATE  12,NP1:PRINT  " NO LOCATE  1 2 , NP 1 + 3 : PR  I  NT  1111 
1680  LOCATE  15, NP1 sPRINT  "FINISH" 

1690  ’LOCATE  16,NPl:PRINT  TIME* 

1700  LOCATE  1 9 , NP 1  - 1 : PR  I  NT  F* (  1 ,  I ): LOCATE  1 9 , NP 1 +7 : PR  I  NT 
F* ( 2 , I )  1705  GOSUB  1000 

1710  RETURN 
1 720  ’ 

1730  ’ 

1740 

'  *****»*■»#,#,**»#*****,*»■»#*##*##*#♦*#*******♦» 
************  1750  ’ 

1760  ’ 

1800  ’  SUBROUTINE  1600  -  LABEL  ARR I VE / DEPART iCIRCl 

D I AGRAM  1810  ’ 

1820  KP- ACT  I  V 1 T  YPOS (  !  )  : GOSUB  2200 

1830  LOCATE  5, NP1  SPRINT  SHORT  ACTE EE CR 1 PT* <  1  , 1 , 1  ) 

1840  LOCATE  6, NP1  SPRINT  SHORT  AC  T DESCR IPTt<2.I,l> 

1850  LOCATE  9,NP1 +3 sPRINT  "NO:" 

1860  ’  LOCATE  1 O , NP 1  +  1  : PR  I N T  1111 
1870  ’LOCATE  12, NP 1  sPRINT  T I  ME  * 


LABEL  DELAY  DIAGRAM 


1880  LOCATE  1 9 , NP 1 +3 : PR I  NT  F4(l,]> 

1885  GGSUB  1800 
1890  RETURN 
1 900  ’ 

1910 

’********************************* 

*************  1980  ’ 

1930  ’ 

8000  ’  SUBROUTINE  8000  - 

8010  ’ 

2080  KP  =  ACT  I  V  I  TYPOS (  I  )  :GOSUB  2200 
2030  LOCATE  5, NP1 :PRINT  SHORTACTDESCR I PT 4 (  1  , I  ,  1  ) 

20*40  LOCATE  6, NP1 sPRINT  SHORT  AC  T  DESCR  I PT*  (  2  ,  I  ,  1  ) 

2050  LOCATE  8,NP1:PRINT  "ENTER" 

2060  ’LOCATE  9,NP1:PRINT  TIME* 

2070  LOCATE  U,NP1:PRINT  "  TOT  LOCATE  1  1  ,  NP 1  *4  :  PR  I  NT  1111 
2080  LOCATE  12,NP1:PRINT  " CUR LOCATE  1 2 , NP 1 +4 : PR  I  NT  1111 
2090  ’LOCATE  15,NP1:PRINT  TIME* 

2100  LOCATE  16,NP1:PRINT  "LEAVE" 

2110  LOCATE  19, NP1-1  SPRINT  FS>  <  1  ,  I  ):  LOCATE  1  9  ,  NP  1 +7  :  PR  1  NT 
F4(2,I>  2115  GOSUB  1400 
2120  RETURN 
2130  ’ 

2140 


*************  2 1  SO  ’ 

8160  ’ 

2200  ’  SUBROUTINE  2200  -  DEFINE  DIAGRAM  POSITION 

22  IP  ’ 

2820  ’ 

8230  IF  KP= 1  THEN  X=20:NP1=4 
2240  IF  KP=2  THEN  X=126:NP1=17 
2250  IF  KP=3  THEN  X=230:NP1=30 
2260  IF  KP=4  THEN  X=334:NP1=43 
2270  IF  KP=5  THEN  X=438:NP1=56 
2280  IF  KP=6  THEN  X=542:NP1=69 
2290  RETURN 
2300  ’ 

2310 


**************  2380 
2330  ’ 

8400  ’  SUBR0U1 

84  10  ’ 

2420  ’ 

8430  LOCATE  2, 88  -.PRINT 
2440  LOCATE  4, 15 -.PRINT 


SUBROUTINE  2400  -  MENU  -  ACTIVITY  TYPE 


8430  LOCATE  2,88:PRINT  "MENU  -  ACTIVITY  TYPE" 

2440  LOCATE  4,15: PR  I  NT  "1.  ARR I VAL / DEPARTURE  ACTIVITY  (ONE 
COLLECTION  POINT)”  2450  LOCATE  6,15:PRINT  "2. 

DELAY /QUEUE /WAIT  ACTIVITY  (TWO  COLLECTION  POINTS)"  2460 
LOCATE  8,15: PR  I  NT  "3.  SERV I CE / AC T I  ON/ AC T I  V  I T Y  (TWO 
COLLECTION  POINTS)"  2470  LOCATE  10,15:PRINT 


DEFINE  COLLECTION 


2510  '• 

2600  ’  SUBROUTINE  2600  - 

SCHEMATIC  2610  ’ 

2620  FCOUNT  =  0 
2630  LOCATE  12.1:PRINT  "PROJECT  NO/ I  DENT  :  " 

2640  LOCATE  12,29:PRINT  " *COL LECT I  ON  SCENARIO  NCI:" 

2650  LOCATE  12,58:PRINT  "*N0  OF  AC T I  V  I T I ES : " : L OCATE 
1 2  , 78 : PR  I  NT  "*"  2660  LOCATE  14,21:PRINT  "ACTIVITY- 
2670  LOCATE  1 4 , 39 : PR  I  NT  "PARALLEL  ACTIVITY  NO:" 

2680  LOCATE  16,6:PRINT  "TYPE  OF  ACTIVITY  (SELECT  FROM 
MENU LOCATE  16,45:PRINT  2690  LOCATE  16,49:PRINT 

"PARALLEL  ACT ( Y/N ):": LOCATE  16,70:PRINT  2700  LOCATE 

1 6 , 72 : PR  I  NT  "NO:":LOCATE  16,78:PRINT 

2710  LOCATE  18,6:PRINT  " DESCR I PT 1  ON  OF  ACTIVITY  (UP  TO  66 
CHARACTERS):"  2720  LOCATE  19,5:PRINT  "*■*":  LOCATE  19,74 :PR1NT 

2730  LOCATE  21,6:PR1NT  "SHORT  DESCRIPTION  TO  BE  USED  TO 
LABEL  SCHEMATIC  (ONE  OR  TWO  WORDS  -  LIMIT"  27-40  LOCATE 
22 , 9 : PR  I  NT  "TO  8  CHARACTERS):" 

2750  LOCATE  23,16:PRINT  "FIRST  WORD :": LOCATE  23,37:PRINT 
"♦SECOND  WORD: " :LOCATE  23,60:PRINT  "**"  2760  RETURN 
2770  ’ 

2780 

’*********************#****-*#*#-******#-*#**#*##*##*##*#*#**-*#-ii 

******  *-***♦*•  *  2790  ’ 

2795  ’ 

2800  ’  SUBROUTINE  2800  -  DEFINE  COLLECTION  SCHEMATIC  - 

INPUTS  2810  LOCATE  12, 19: INPUT  PROJECT * 

2820  LOCATE  12,54: INPUT  SCENARIO* 

2825  IF  LEN ( SCENARIO* )=1  THEN  SCENAR I 0*= ” O " +SCENAR 10* 

2830  LOCATE  12,75: INPUT  N 
2840  FOR  I  =  1  TO  N 
2850  ACT  I  VI  TYPOS ( I  >  =  1 
2860  LOCATE  14,31 :PRINT  I 

2870  LOCATE  16,42:  INPUT  ACT  I  V  I T YT YPE (  I  ) 

2880  LOCATE  16,67; INPUT  AN* 

2890  IF  AN*= " N "  THEN  GOTO  2910 
2900  LOCATE  16,75: INPUT  PARACTNO(I) 

2910  IF  PARACTNO ( I ) =0  THEN  PARACTNO < I > = 1 
2920  FOR  J=  1  TO  PARACTNO(l) 

2930  LOCATE  14,61 :PRINT  J 

2940  LOCATE  19,6:  INPUT  LONGACTDESCR I PT  * (  I , J  ) 

2950  LOCATE  23,27: INPUT  SHORT ACTDESCR I PT * ( 1 , I , J > 

2960  LOCATE  23,50:  INPUT  SHORT ACTDE5CRIPT*(2,  I  ,J  ) 

2970  IF  PARACTNO ( I ) V 1  THEN  GOSUB  3150 
2980  NEXT  J 

2985  IF  CHG%=1  THEN  CHGV.  =  0  :  RE  T  UP.N 
2990  FCOUNT  -  FCOUNT  +  1 

3000  GOSUB  S'.'OOO 


3010  IF  ACT  I  V 1 T  YT YPE (  I  >  > 1  THEN  F  COUNT  =F COUNT  + 1 

3020  GDSUB  3100 

3030  NEXT  I 

3040  RETURN 

3050 

3060 

’#*****#«*«■#*#**##»■♦***«■#♦*******«****«■*♦**#**#***♦#♦«.**•**** 
♦  ♦♦♦■it'd-******  3070  ’ 

3080  ’ 

3100  '  SUBROUTINE  3100  -  CLEAR  INPUT  SPACES 

3110  ’ 

3120  ’ 

3130  LOCATE  14,62:PRINT  "  " : L  OCATE  16,44:PRINT  "  " : LOCATE 
1 6 , 69 : PR  1  NT  "  " : LOCATE  16,77:PRINT  "  "  3140  LOCATE 
14,31 :PRINT  "  " 

3150  ’  MINI -SUB  -  CLEAR  ONLY  FOR  PARALLEL  ACT  INPUTS 

3160  LOCATE  19,6:PRINT  " 

"  3170  LOCATE  23,27:PRINT  " 

3180  LOCATE  23, 52: PR  I  NT  " 

3190  RETURN 
3200  ’ 

3210  ’ 

*****  ******************************************************** 
*********** *  3220  ’ 

3230  ’ 

3300  ’  SUBROUTINE  3300  -  WRITE  SCHEMATIC  DEFINITION  TO 

FILE  3310  ’ 

3320  ’  ASSUMES  DATA  DISK  IS  IN  DRIVE  B 
3330  ’ 

3340  ’ 

3350  IF  LEN ( SCENAR I  0* )  =  1  THEN  SCENAR I  0* = " O " +SCENAR I  0$ 

3360 

F I LE$  =  " B : "  +  " PR "+LEFT* (PROJECT* ,4 ) +R I GHTi ( SCENAR I  0* , 2 )  +  " . SDF " 
3370  ’ 

3380  OPEN  "O" ,#1 ,FILEt 

3390  WRITE  # 1 , PRO JECT4 , SCENAR I  0$ , N 

3400  FOR  I  =  1  TO  N 

3410  WRITE  #1  , ACT  I  VI  TYPOS <  I  >  , ACT  I  V  I TYT YPE (  I  )  ,PARACTNO(  I  ) 

3420  FOR  J  =  1  TO  PARACTNO ( I ) 

3430  WRITE  # 1 , LONGACTDESCR I PT$ ( I , J ) 

3440  WRITE 

#1  , SHORT  ACT DE SCR  I PTt ( 1  , I , J ) , SHORT  ACT DE SCR  I PT  $ ( 2 , I , J )  3450 
NEXT  J 

3460  WRITE  # 1  ,  F* (  1  , I  ) ,F (  1  , I  ) ,F$ ( 2 , I ) ,F ( 2 , I  ) 

3470  NEXT  I 
3400  CLOSE  #1 

3485  SCREEN  2 

3486  RETURN 

3490  ’ 

3500  ' 

************************************************************* 
***********  35  ir>  ’ 

3520  ’ 


<r. -".-'v'"-  9 
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3600  ’  SUBROUTINE  3600  -  RETRIEVE  SCHEMATIC  DEFINITION 

FROM  FILE  3610  ’ 

3620  ’ 

3630  CLS: SCREEN  1 

3640  LOCATE  4,5:  INPUT  "ENTER  PROJECT  NO/ I  DENT  :  "  ;  PRO  JECT* 

3650  LOCATE  6,5: INPUT  "ENTER  SCENARIO  NO : " ; SCENAR 1 0* 

3655  IF  LEN ( SCENAR I  0* )  =  1  THEN  SCENAR I D*  = " O " +SCENAR I O* 

3656  LOCATE  8,5: INPUT  "ENTER  STUDY  #: "5  STUDY* 

3660  FILE*  = 

" B : "+"PR"+LEFT*( PROJECT  *,9)+RIGHT*( SCENAR 1 0* , 2 )  +  " . SDF "  3670  ’ 
3680  OPEN  "I "  ,#1 .FILE* 

3690  INPUT  #1 .PROJECT*, SCENARIO*, N 
3700  FOR  1  =  1  TO  N 

3710  INPUT  # 1 , ACT IVITYPOS( I ) ,ACTIVITYTYPE< I ) , PAR ACT NO ( I > 

3720  FOR  J  =  1  TO  PARACTNO(I) 

3730  INPUT  # 1 , LONGACTDESCR I PT* ( I , J ) 

3740  INPUT 

#1 , SHORT  ACT DE SCR  I PT* ( 1 , I , J) , SHORT  ACTDESCR I PT* ( 2 ,  I , J)  375n 
NEXT  J 

3760  INPUT  #1 ,F*< 1 , I ) ,F ( 1 , I > ,F*<2, I > ,F (2, I > 

3770  NEXT  I 
3780  CLOSE  #1 
3790  SCREEN  2 
3795  ’ 

3800  * 

3810  ’ 

************************************************************* 
***********  3820  ’ 

3830  ’ 

3900  ’  SUBROUTINE  3900  -  DISPLAY  PROJECT  FILE 

CONTENTS  3910  ’ 

3920  ’  LABEL  PAGE 

3930  LOCATE  1,8:PRINT  "PROJECT  NO/ I  DENT LOCATE  1,36:PRINT 
"SCENARIO  NO : " : LOCATE  1,54:PRINT  "NO  OF  ACTIVITIES:"  3990 
LOCATE  3,4: PR  I  NT  "ACT  I V  I TY# " : LOCATE  3,17:PRINT  " TYPE ": LOCATE 
3 , 27 : PR  I  NT  "PARALLEL LOCATE  3,39:PRINT  "SHORT 
ACTIVITY" : LOCATE  3,57:PRINT  "F  KE Y ( S )": LOCATE  3,70:PRINT 
"FILE" 

3950  LOCATE  4,7:PRINT  "#":LOCATE  4,15:PRINT 

"ACTIVITY"  :LOCATE  4,27:PRINT  " ACT  1 V  I TY ": LOCATE  4,40:PRINI 

"DESCRIPTION" :LOCATE  4,68:PRINT  "SEQUENCE  #" 

3960  LOCATE  5,4:PR1NT  " - 

- ••  3970  ’  DISPLAY  DATA 

3980  LOCATE  1,26:PRINT  PRO JECT* : LOCATE  1.49:PRINT 
SCENARIO* :LOCATE  1,72:PRINT  N  3990  K=5:FC=1 

4000  FOR  I  =  1  TO  N 
4010  K  =  K  +  1 

4020  LOCATE  K,7:PRINT  I:LOCATE  K.18.-PR1NT  ACT  I VI TYTYPE <  I  > 
4030  K 1 =0 

4040  FOR  J  =  1  TO  PARACTNO  <  I  ) 

4050  LOCATE  K,30:PRINT  J:LOCATE  K.39:PRINT 

SHORT ACT DESCRIPT* (  1  , I  , J )  +  "  " ; SHORT ACTDESCR I PT* ( 2 ,  I  , J )  9  0fo'  * 

IF  K1  =  1  THEN  GOTO  9085 


4060  IF  K1  =  1  THEN  GOTO  4085 

4o?0  IF  ACT IOITYTYPE( I )=1  THEN  K1=1:L0CATE  K,58:PRINT 

F$( 1 . I ) : GOTO  4085  4080  LOCATE  K,58:PRINT 

F$(  1  ,  I  >+"  ,  "+F*<8,  I  )  : K  1  =  1 

4085  LOCATE  K,70:PRINT  FC 

4090  IF  K= 1 8  THEN  GOSUB  5100 

4100  K  =  K  +  1 : FC=FC+ 1 

4110  NEXT  J 

4180  IF  K=1B  THEN  GOSUB  5100 
4130  NEXT  I 

4140  LOCATE  S3  ,  4 : PR  I  NT  "PRESS  ANY  KEY  TO  CONTINUE" 

4150  IF  INKEY*=""  THEN  GOTO  4150 
4160  RETURN 
4  170 
4180 

’**##*##***#*##*-i<-*#-**-****-*****-******##**#**#******##**-**#*** 

t*******«*«*** 

4  190  ’ 

4800  ’ 

5100  LOCATE  83,4:PRINT  "PRESS  ANY  KEY  TO  CONTINUE" 

5110  IF  I NKEY* = " "  THEN  GOTO  5110 

5180  GOSUB  51000 

5130  K  =  5 

5140  RETURN 

5150  ’ 

5160 

’*******»♦♦»***♦#»»*#*#*##*#♦##****»*****»#♦♦»♦*»*****»«'#*** 
**♦+**«  +  ***•***« 

5170  ’ 

5180  ’ 

5300  ’  SUBROUTINE  5300  -  COLLECT  DATA 

5310  ’ 

5380  ’ 

5330  FOR  11=1  TO  10 
5340  KEY  II,"" 

5350  NEXT  II 

5355  S*  =  T  I  ME* : LOCATE  8,19:PRINT  5* 

5360  FKEY*=INKEY* : IF  F KE Y* = " "  THEN  GOTO  5360 
5370  IF  LEN ( FKEY* ) = 1  THEN  GOTO  5360 
5380  IF  LEN ( FKEY* ) =8  THEN 

FKEY*=RI GHT  *  <  FKE Y* ,  1  ):V=ASC(FKEY*)  5390  IF  O  =  103  THEN 
E*  =  T I  ME* : LOCATE  8,43:PRINT  E* : RETURN  5400  T*- T I  ME* 

54  10  GOSUB  5500  ’I  DENT  F  KEY 

5480  GOSUB  5700  ’ENTER  INTO  ARRAY 

5430  ON  ACT  I  V  I TYT YPE (  I  )  GOSUB  6000 , 6300 , 6500 

5440  GOTO  5360 

5450  ’ 

54t>0 

«**##**#****»* 

5470  ’ 

5480  ’ 

5500  ’  SUBROUTINE  5500  -  IDENTIFY  WHICH  F  KEN  WAS  PRESSED 


101 


5510 

' 

5520 

* 

5530 

FOR  I 

5540 

FOR  J  ! 

5550 

IF  V  = 

5560 

NE  XT  J 

5570 

NEXT  I 

5580 

KP=  I 

5590 

RETURN 

5600 
56  10 

> 

TO 

TO 


N 

2 


THEN  GOTO  5580 


#****#«'#*##«'*# 

5620  ’ 

5630  ’ 

5700  ’  SUBROUTINE  5700  -  ENTER  DATA  COLLECTED  INTO  ARRAY 

5710  ’ 

5720  ’ 

5730  IF  PARACTNO ( I ) > 1  THEN  GOSUB  5820:G0T0  5750 
5740  K  =  1 

5750  M  =  LAST  (  I  ,  J  ,  K  )  : M=M+ 1 

5755  T=(VAL(LEFT4<T*,2) ) ) *60  +  VAL ( MI D* < T* , 4 , 2 ) )  + 

(  ( VAL ( R I GHT *  <  T* , 2 )  ) )  /  60 )  5756  LOCATE  2,72:PRINT  FRE(O) 

5760  FI <M, I ,J,K)=T 

5770  IF  ACT IVITYTYPE( I )=1  THEN 

NOTHROUGH (  I  , K ) =NOTHRQUGH  <  I  , K )  +  1 

5780  IF  J=1  AND  ACT  I  V  I TYT YPE (  I  ) =2  THEN  NOIN<I,K>  = 

NOIN(  I ,K)  +  1  : IF  NO I N< I ,K ) > MAX CON (  I  ,  K  >  THEN  MAXCONT ( I  , K )  = 

NO I N (  I  , K  > 

5790  IF  J  =  2  AND  ACT  I  V  I T YT YPE (  I  > < >  1  THEN 

SUMNOIN<  I  ,K)=SUMNOIN<  I  ,K)+NOIN<  I  ,  K  )  :  NO  I  N  (  I  ,tO=NOIN<  1  ,  K  )  - 

1  :  NOTHROUGH  (  I  ,  K  )  =NOTHROUGH  (  I  ,K>  +  1  :  IF  NOIN(I,KXO  THEN 

NO  I N ( I , K ) =0 

5800  LAST  (I,J,K)=M 

5810  RETURN 

5815  ’ 

5820  ’  INTERNAL  SUBROUTINE  5820  -  FIND  OUT  PARALLEL 

ACTIVITY  NO 
5830  ’ 

5840  LOCATE  23,5:PRINT  "ENTER  PARALLEL  ACTIVITY  NUMBER" 

5841  AN*=INKEY*: IF  AN*^'"  THEN  GOTO  5841 

5842  IF  AN*=" 1"  THEN  K=1 

5843  IF  AN*="2"  THEN  K=2 

5844  IF  AN* = " 3 "  THEN  K=3 

5845  IF  AN*  = " 4 "  THEN  K=4 

5846  IF  AN*= "5 ”  THEN  K=5 

5847  IF  AN*  = " 6 "  THEN  K  =  6 
5850  LOCATE  23, 5: PR  I  NT  " 

5860  RETURN 

5870  ’ 

5880  ’  *********************************************** 
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5895 
6000 
6010 
6080 
6030 
6090 
6050 
6060 
6070 
6080 
6090 
***** 
6100 
6110 
6300 
6310 
6380 
6330 
6390 
6350 
6360 
6370 
6380 
NO  I  N  ( 
6390 
6900 
6910 
6980 
6930 
NO  I  N  ( 
6990 
6950 
6960 
***** 
6970 
6980 
6500 
6510 
6580 
6530 
6590 
6550 
6560 
6570 
6580 
6590 
6600 
6610 
668  C' 
6630 
6690 
6650 


’  SUBROUTINE  6000  -  UPDATE  DISPLAY  -APR  I VAL / DEPART URE 


GOSUB  8800 

LOCATE  6  ,  NP 1  : PR  I  NT  SHORT ACTDESCR I PT t < 8 , I , K ) 
LOCATE  10*  NP 1  +  1 :PRINT  NOTHROUGH < I , K > 

LOCATE  18, NP1 :PRINT  Tt 
RETURN 

> 

’****************************************** 
(■*******  *********  ********** 


SUBROUTINE  6300  -  UPDATE  DISPLAY  -  DELAY 


GOSUB  8800 

LOCATE  6, NP1 SPRINT  SHORT ACTDESCR I PT* ( 8 , I , K ) 

IF  3=8  THEN  GOTO  6910 
LOCATE  9, NP1 SPRINT  Tt 

LOCATE  1 1 ,NP 1+9  SPRINT  NOTHROUGH (  I , K ) 

LOCATE  IS, NP1+9 SPRINT  "  "sLOCATE  1 8 , NP 1 +9 s PR  I  NT 

:  i ,  k  ) 

LOCATE  1 5, NP1 SPRINT  " 

GOSUB  1900 s RETURN 
LOCATE  9, NP1 SPRINT  " 

LOCATE  1 1 ,NPl+9sPRINT  NOTHROUGH ( I , K ) 

LOCATE  18, NP1+9 SPRINT  "  "sLOCATE  1 8 , NP 1 +9 s PR  I  NT 
I, K)  sLOCATE  15, NP1  SPRINT  Tt 
GOTO  6900 

’************************************************* 

(■******************* 


SUBROUTINE  6500  -  UPDATE  DISPLAY  -SERV I CE / AC T I  V  I T Y 


GOSUB  8800 

LOCATE  6, NP1 SPRINT  SHORT ACTDESCRIPTt<2, I  ,K  ) 
IF  J=2  THEN  GOTO  6600 
LOCATE  9, NP1 SPRINT  Tt 

LOCATE  1 8 , NP l+3sPRINT  NOTHROUGH ( I , K ) 

LOCATE  16, NP1 SPRINT  " 

GOSUB  1000 s RETURN 
LOCATE  9, NP1 SPRINT  " 

LOCATE  18,NPl+3sPRINT  NOTHROUGH ( I , K ) 

LOCATE  16, NP1 SPRINT  Tt 
GOTO  6590 

> 


iOOCftt 
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6660 

6670 

9000 

9010 

9020 

9030 

9040 

9050 

9055 

9056 
9060 
9065 
9150 
9153 

9155 

9156 
9170 
9180 
9190 
9200 
9210 


SUBROUTINE  9000  -  SAVE  COLLECTION  DATA  TO  FILES 


FOR  I  =  1  TO  N 

FOR  K  =  1  TO  PARACTNO(I) 

COUNT  =  COUNT  +  1 :COUNT*=STR*( COUNT > 

IF  COUNT  <10  THEN  Kl  =  l  ELSE  Kl=2 
COUNT  *  =  R  I GHT  * ( COUNT  * ,  K  1  ) 

IF  LEN ( COUNT  * )  =  1  THEN  COUNT*= " 0" + COUNT  * 

IF  I>1  THEN  GOTO  9156 

IF  LEN< SCENARIO* >  =  1  THEN  SCENAR 1 0*= " O " +SCENAR I  0* 

IF  LEN  <  STUDY* )  =  1  THEN  STUDY*= " 0 " +STUDV* 

F I N*= " B : " +LEFT  *<PR0JECT*,2)+RIGHT*( SCENAR I0*,2)+STUDY* 
F I L*=F I N*+R I GHT  * ( COUNT* , 2 )  +  " . SCF " 

OPEN  "0" ,  #  1 ,  F  I  L* 


9170  OPEN  "0" ,  #  1 ,  F  I  L* 

9180  WRITE  #1 .PROJECT*, SCENARIO*, N 
9190  WRITE  # 1 , ACT IVITYTYPE( I > ,  K  , I 
9200  WRITE  #1 , LONGACTDESCR I PT* ( I ,K  > 

9210  WRITE  # 1 , SHORT  ACT DE SCR IPT*<1,I,K>, SHORT  ACT  DE SCR  I PT* 
(2, I ,K) 

9220  WRITE  # 1 , STUDY* , DATE* , S* , E* 

9230  WRITE  # 1 , L AST ( I , 1 , K > 

9240  WRITE  # 1  , NOTHROUGH (  I , K  )  , MAXCONT  <  I , K  > 

9245  IF  ACT  I V I T YTYPE ( I  )=2  THEN 

QLENAVG=SUMNOIN< I ,K ) /LAST ( I , 1 ,K>  ELSE  DLENAVG=0  9250 
IF  ACT  I  V  I TYT YPE < I  )  =  1  THEN  GOSUB  9500 


9260  IF  ACT  I  VI TYT YPE (I><>1  THEN  GOSUB  9700 

9270  CLOSE  #1 

9280  NEXT  K 

9290  NEXT  I 

9300  RETURN 

9310  ’ 

9320 

’ ****#***#*****#************#*#**#+##******#****##***#****+# 
♦  ♦■it-*#********# 

9330  ’ 

9340  ’ 

9500  '  SUBROUTINE  9500  -  SAVE  TO  FILE  TYPE  1  DATA 

9510  ’ 

9520  ’ 

9530  ET=0:ETT=0:ETNAX=0:ETAVG=0 
9540 

ST= ( VAL (LEFT*(S*,2) ) ) *60+ ( VAL < M I D* ( S* , 4 , 2 ) ) > + ( VAL ( R I GHT* ( S* , 
2  )  )  )  / 60 

9550  ET=F1 ( 1 , I , 1 ,K)-ST:M=1 
9560  WRITE  # 1 , M , F 1 ( 1 , I , 1 , K > , ET 
9570  ETT  =  ETT  +ET 

9580  FOR  M  =  2  TO  LAST<I,1,K> 

9590  ET=F1 (M, I . 1 ,K)-F1 (M-l , I , 1 ,K) 

9600  WRITE  #1 ,M,F1 (M, I , 1 ,K ) ,ET 
9610  ETT=ETT+ET 


SUBROUTINE  9500  -  SAVE  TO  FILE  TYPE  1  DATA 


L 


9620  IF  ET>ETMAX  THEN  ETMAX=ET 

9630  NEXT  M 

9640  ETA0G=ETT/M 

9650  WRITE  # 1 , ET AVG , ETMAX 

9660  RETURN 

9670  7 

9680 

7*********************************************************** 

************** 

9690  7 
9695  ’ 

9700  7  SUBROUTINE  9700  -  SAVE  TO  FILE  TYPE  2&3  DATA 

9710  ’ 

9720  ’ 

9730  ET=0:ETT  =  0: ETMAX =0 : ET  AVG=0 
9740  FOR  M  =  1  TO  LAST(I,1,K) 

9750  ET=F1 <M, I ,2,K)-F1 <M, I , 1 ,K> 

9760  WRITE  # 1 , M ,F 1 < M , I , 1 , K ) , F 1 < M , I , 2 , K > , ET 
9770  ETT=ETT+ET 

9780  IF  ET >ETMAX  THEN  ETMAX=ET 
9790  NEXT  M 
9800  ETAVG=ETT/M 

9810  WRITE  #1 ,ETAVG, ETMAX ,QLENAVG 
9820  RETURN 
9830  ’ 

9840 

’*********************************************************** 

************** 

9850  ’ 

9860  ’ 

10000  ’  SUBROUTINE  10000  -  PRINT  DIAGRAM  HEADER 

10010  ’ 

10020  ’ 

10030  CLS 

10040  LOCATE  1,1  SPRINT  "PROJECT  NO/ 1  DENT :  ";PROJECT* 

10050  LOCATE  1,30:PRINT  "SCENARIO  NO:  " SCENARIO* 

10060  LOCATE  1,62:PRINT  "STUDY  NO:  " ;STUDY* 

10070  LOCATE  2,7:PRINT  "START  TIME:" 

10080  LOCATE  2,32:PRINT  "STOP  TIME:" 

10090  LOCATE  2,54:PRINT  "MEMORY  REMAINING:" 

10100  RETURN 
10110  7 
10120 

’*********************************************************** 

************* 

10130  7 
10140  7 

11000  7  SUBROUTINE  11000  -  MODIFY  DIAGRAM 

11005  7 

1 1 006  7 

11010  FCOUNT  =  0 

11015  LOCATE  22,1: INPUT  "DO  YOU  WANT  TO  MAKE  ANY  CHANGES 
<  Y/N )  : " ?CH$ 


1 1 020  IF  CH*= "N"  THEN  GOTO  3  I  1 25 
11025  GOSUB 

1 1 500 : LOCATE  22,1: INPUT  "DO  YOU  WANT  TO  CHANGE  THE  SCENARIO 
NO  < Y/N ) : " ; AN* 

11030  IF  AN*="N"  THEN  GOTO  11040 

11035  GOSUB  1 1500: LOCATE  22,1: INPUT  "INPUT  NEW  SCENARIO 
NO. : " ; SCENARIO* 

11040  GOSUB 

1 1500: LOCATE  22,1:PRINT  "Do  you  want  to  CHANGE 
a  symbol  (1),  ADD  a  symbol  (2),  or  DELETE  a  symbol  <3)." 
11045  LOCATE  23,1: INPUT  "ENTER  1 , 2 , DR  3 : " ; CH 
11050  ON  CHGOTO  11055,11135,11135 

11055  GOSUB  1 1 500 : LOCATE  22,1: INPUT  "WHICH  ACTIVITY  TO  YOU 

WANT  TO  CHANGE  ( 1 , 2 , 3 , 4 , 5 , OR  6>:";I:CLS 

11060  GOSUB  2400  ’PRINT  ACTIVITY  MENU 

11065  GOSUB  2600  ’PRINT  INPUT  FORMAT 

11070  CHG*/.=  1  :  GOSUB  2B50 

11075  FOR  I  =  1  TO  N  ’RELABEL  FKE Y  LABELS 

11000  ACTIVITYPOS< I >=I 
11085  FCOUNT  =FCOUNT  + 1 
11090  GOSUB  50000 

11095  IF  ACT IVITYTYPE <  I >=2  OR  ACT  I V  I T YTYPE <  I  )  = 3  THEN 
FCOUNT  =  FCOUNT  + 1  11100  NEXT  I 

11105  GOSUB  10000 
11110  GOSUB  700 

11115  LOCATE  22,1: INPUT  "DO  YOU  WANT  TO  MAKE  ANOTHER  CHANGE 
<  Y/N ) : ” ; CH*  11120  IF  CH*= " Y "  THEN  FC0UNT=0 : GOTO  11040 
11125  RETURN 

11130  ’  ADD  A  SYMBOL 

11135  GOSUB  1 1 500 : LOCATE  22,1:PRINT  "PROGRAMMING  IN 
PROGRESS" :FOR  Y=1  TO  1 000 : Y  =  Y+ 1 : NE XT  Y 
11140  GOTO  11115 

11500  ’  SUBROUTINE  11500  -  CLEAR  LINE  22 

11505  ’ 

11510  ’ 

11515  LOCATE  22,1:PRINT  " 

11516  LOCATE  23,1:PRINT  " 

•  I 

11520  RETURN 
11525  ’ 

1  1530 

’**#**•»*♦#**#♦*»**♦*##*#*#*****#•***•»♦**#»#»*#*****#**##****# 

***«****»♦«■** 

11535  ’ 

11540  ’ 

50000  ’  SUBROUTINE  50000  -  ASSIGN  F  KEY 

50010  ’ 

50020  7 

50030  IF  F  COUNT  =  3  THEN 

F*< 1 , I >="F1 " :F( 1 , I ) =59 : F* ( 2 , I > - " F2 ’ : F ( 2 , I >=60: GOTO  50150 
50040  IF  FCOUNT  =2  THEN 

F*<  1 , I  )="F2" :F<  1 , I ) =60 : F * ( 2 , I>  =  "E3":F(2,I>=61  :GOTO  50150 


I  at  1.4  aIJvL|l  »-•  *-€  |.l 


i**  K*  It'.UMi*  b'  k*.b'  ‘  Jl|  'll  Jb  *  .k 1  -W’ll*  ■  i 


L 


50050  IF  FCOUNT  =  3  THEN 

Ft  < 1 ) I )="F3":F( 1 ,  I )  =61 :F$(2|I )  =  "F4 " : F  <  2  » I >=62: GOTO  50150 
50060  IF  FCOUNT =4  THEN 

F*<  1  , I  )="F4" :F< 1 , I )=62:Ft<2, I  >  =  "F5 ":F(2,  I  >=63: GOTO  50150 
50070  IF  FCOUNT =5  THEN 

Ft  <  1 , I  >  =  "F5" :F<  1 , I >=63: Ft <2,  I  >  =  " F6 " : F < 2 , I  >=64 :G0T0  50150 
50080  IF  FCOUNT =6  THEN 

Ft (  1 , I  )  =  "F6" sF ( 1 , I  ) =64 : Ft ( 2 ,  I  >  =  " F7 " : F ( 2 , I  ) =65: GOTO  50150 
50090  IF  FCOUNT  =7  THEN 

Ft (  1 , I  )  =  "F7" :F ( 1 , I  > =65: Ft ( 2  ,  I  >  ="F8" : F ( 2 , I  ) =66 : GOTO  50150 
50100  IF  FCOUNT  =  8  THEN 

Ft  <  1  ,  I  >  =  "F8"  :F  (  1  ,  I  )  =66  :  Ft  (  2  ,  I  >  =  ,,F9  "  :  F  (  2 ,  I  >=67  :  GOTO  50150 
50110  IF  F  COUNT  =  9  THEN 

Ft  <  1  ,  I  >  =  "F9”  :F<  1  ,  I  )=67:Ft<2,  I  >  =  "  F  1  0  "  :  F  (  2  ,  I  >=68  .-GOTO  50150 

50120  IF  FCOUNT  =10  THEN  Ft<l,I>  =  "F10'':F<l,I>=6B:Ft(2,I>  =  "S- 

F  1  "  :  F  (  2  ,  I  )  =89  :  GOTO  50150  50130  IF  FC0UNT=11  THEN 

Ft ( 1 , I  )  =  "S-F 1 " :F ( 1 , I  ' =84 :Ft  <2  ,  I  >="S-F2" :F ( 2, I  ) =85: GOTO  50150 

50140  IF  FCOUNT  =12  THEN  Ft(l,I)="S  =  F2":F(l,I>- 

85 : Ft ( 2 , I ) = "S-F3" :F (2, I )=86: GOTO  50150  50150  IF 

ACT  I  V  I TYTYPE (  I  )  =  1  THEN  F(2,I>=0 

50160  RETURN 

50170  ’ 

50180 

’****»*#****»**♦***»*♦##*#****#»«**♦*♦*»*♦*#»**»♦*♦***»****« 

#***#■**•*■****•# 

50190  ’ 

50200  ’ 

51000  ’  SUBROUTINE  51000  -  CLEAR  BOTTOM  HALF  OF  SCREEN 

FOR  DATA  DISPLAY 
51010  ’ 

51020  FOR  K  =  6  TO  10 
51030  LOCATE  K,3:PRINT  " 

51040  NEXT  K 
51050  RETURN 
51060  ’ 

51070 

’****  +  #♦*#*♦*#***#*♦♦**#**«##■»*#*♦*###*#*♦#****#**►*#***#*** 
*#*«##*#****** 

51080  ’ 

51090  ’ 

60000  IF  ERR= 1 6  THEN  E=E+ 1 : RESUME  0 
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